Which of the following statements is not correct about the use of function

Note: Sometimes you'll see the default, non-strict mode referred to as sloppy mode. This isn't an official term, but be aware of it, just in case.

JavaScript's strict mode is a way to opt in to a restricted variant of JavaScript, thereby implicitly opting-out of "sloppy mode". Strict mode isn't just a subset: it intentionally has different semantics from normal code. Browsers not supporting strict mode will run strict mode code with different behavior from browsers that do, so don't rely on strict mode without feature-testing for support for the relevant aspects of strict mode. Strict mode code and non-strict mode code can coexist, so scripts can opt into strict mode incrementally.

Strict mode makes several changes to normal JavaScript semantics:

  1. Eliminates some JavaScript silent errors by changing them to throw errors.
  2. Fixes mistakes that make it difficult for JavaScript engines to perform optimizations: strict mode code can sometimes be made to run faster than identical code that's not strict mode.
  3. Prohibits some syntax likely to be defined in future versions of ECMAScript.

Strict mode applies to entire scripts or to individual functions. It doesn't apply to block statements enclosed in

function sum(a = 1, b = 2) {
  // SyntaxError: "use strict" not allowed in function with default parameter
  "use strict";
  return a + b;
}
2 braces; attempting to apply it to such contexts does nothing.
function sum(a = 1, b = 2) {
  // SyntaxError: "use strict" not allowed in function with default parameter
  "use strict";
  return a + b;
}
3 code,
function sum(a = 1, b = 2) {
  // SyntaxError: "use strict" not allowed in function with default parameter
  "use strict";
  return a + b;
}
4 code, attributes, strings passed to
function sum(a = 1, b = 2) {
  // SyntaxError: "use strict" not allowed in function with default parameter
  "use strict";
  return a + b;
}
5, and related functions are either function bodies or entire scripts, and invoking strict mode in them works as expected.

To invoke strict mode for an entire script, put the exact statement

function sum(a = 1, b = 2) {
  // SyntaxError: "use strict" not allowed in function with default parameter
  "use strict";
  return a + b;
}
6 (or
function sum(a = 1, b = 2) {
  // SyntaxError: "use strict" not allowed in function with default parameter
  "use strict";
  return a + b;
}
7) before any other statements.

// Whole-script strict mode syntax
"use strict";
const v = "Hi! I'm a strict mode script!";

Likewise, to invoke strict mode for a function, put the exact statement

function sum(a = 1, b = 2) {
  // SyntaxError: "use strict" not allowed in function with default parameter
  "use strict";
  return a + b;
}
6 (or
function sum(a = 1, b = 2) {
  // SyntaxError: "use strict" not allowed in function with default parameter
  "use strict";
  return a + b;
}
7) in the function's body before any other statements.

function myStrictFunction() {
  // Function-level strict mode syntax
  "use strict";
  function nested() {
    return "And so am I!";
  }
  return `Hi! I'm a strict mode function! ${nested()}`;
}
function myNotStrictFunction() {
  return "I'm not strict.";
}

The

function myStrictFunction() {
  // because this is a module, I'm strict by default
}
export default myStrictFunction;
0 directive can only be applied to the body of functions with simple parameters. Using
function myStrictFunction() {
  // because this is a module, I'm strict by default
}
export default myStrictFunction;
0 in functions with rest, default, or destructured parameters is a syntax error.

function sum(a = 1, b = 2) {
  // SyntaxError: "use strict" not allowed in function with default parameter
  "use strict";
  return a + b;
}

The entire contents of JavaScript modules are automatically in strict mode, with no statement needed to initiate it.

function myStrictFunction() {
  // because this is a module, I'm strict by default
}
export default myStrictFunction;

All parts of a class's body are strict mode code, including both and .

class C1 {
  // All code here is evaluated in strict mode
  test() {
    delete Object.prototype;
  }
}
new C1().test(); // TypeError, because test() is in strict mode

const C2 = class {
  // All code here is evaluated in strict mode
};

// Code here may not be in strict mode
delete Object.prototype; // Will not throw error

Strict mode changes both syntax and runtime behavior. Changes generally fall into these categories:

  • changes converting mistakes into errors (as syntax errors or at runtime)
  • changes simplifying how variable references are resolved
  • changes simplifying
    function sum(a = 1, b = 2) {
      // SyntaxError: "use strict" not allowed in function with default parameter
      "use strict";
      return a + b;
    }
    
    3 and
    function myStrictFunction() {
      // because this is a module, I'm strict by default
    }
    export default myStrictFunction;
    
    3
  • changes making it easier to write "secure" JavaScript
  • changes anticipating future ECMAScript evolution.

Strict mode changes some previously-accepted mistakes into errors. JavaScript was designed to be easy for novice developers, and sometimes it gives operations which should be errors non-error semantics. Sometimes this fixes the immediate problem, but sometimes this creates worse problems in the future. Strict mode treats these mistakes as errors so that they're discovered and promptly fixed.

Assigning to undeclared variables

Strict mode makes it impossible to accidentally create global variables. In sloppy mode, mistyping a variable in an assignment creates a new property on the global object and continues to "work". Assignments which would accidentally create global variables throw an error in strict mode:

"use strict";
let mistypeVariable;

// Assuming no global variable mistypeVarible exists
// this line throws a ReferenceError due to the
// misspelling of "mistypeVariable" (lack of an "a")
mistypeVarible = 17;

Failing to assign to object properties

Strict mode makes assignments which would otherwise silently fail to throw an exception. There are three ways to fail a property assignment:

  • assignment to a non-writable data property
  • assignment to a getter-only accessor property
  • assignment to a new property on a non-extensible object

For example,

function myStrictFunction() {
  // because this is a module, I'm strict by default
}
export default myStrictFunction;
4 is a non-writable global variable. In sloppy mode, assigning to
function myStrictFunction() {
  // because this is a module, I'm strict by default
}
export default myStrictFunction;
4 does nothing; the developer receives no failure feedback. In strict mode, assigning to
function myStrictFunction() {
  // because this is a module, I'm strict by default
}
export default myStrictFunction;
4 throws an exception.

"use strict";

// Assignment to a non-writable global
var undefined = 5; // TypeError
var Infinity = 5; // TypeError

// Assignment to a non-writable property
const obj1 = {};
Object.defineProperty(obj1, "x", { value: 42, writable: false });
obj1.x = 9; // TypeError

// Assignment to a getter-only property
const obj2 = {
  get x() {
    return 17;
  },
};
obj2.x = 5; // TypeError

// Assignment to a new property on a non-extensible object
const fixed = {};
Object.preventExtensions(fixed);
fixed.newProp = "ohai"; // TypeError

Failing to delete object properties

Attempts to delete a non-configurable or otherwise undeletable (e.g. it's intercepted by a proxy's

function myStrictFunction() {
  // because this is a module, I'm strict by default
}
export default myStrictFunction;
7 handler which returns
function myStrictFunction() {
  // because this is a module, I'm strict by default
}
export default myStrictFunction;
8) property throw in strict mode (where before the attempt would have no effect):

"use strict";
delete Object.prototype; // TypeError
delete [].length; // TypeError

Strict mode also forbids deleting plain names.

function myStrictFunction() {
  // because this is a module, I'm strict by default
}
export default myStrictFunction;
9 in strict mode is a syntax error:

"use strict";

var x;
delete x; // syntax error

If the name is a configurable global property, prefix it with

class C1 {
  // All code here is evaluated in strict mode
  test() {
    delete Object.prototype;
  }
}
new C1().test(); // TypeError, because test() is in strict mode

const C2 = class {
  // All code here is evaluated in strict mode
};

// Code here may not be in strict mode
delete Object.prototype; // Will not throw error
0 to delete it.

"use strict";

delete globalThis.x;

Duplicate parameter names

Strict mode requires that function parameter names be unique. In sloppy mode, the last duplicated argument hides previous identically-named arguments. Those previous arguments remain available through

function myStrictFunction() {
  // because this is a module, I'm strict by default
}
export default myStrictFunction;
3, so they're not completely inaccessible. Still, this hiding makes little sense and is probably undesirable (it might hide a typo, for example), so in strict mode, duplicate argument names are a syntax error:

function myStrictFunction() {
  // Function-level strict mode syntax
  "use strict";
  function nested() {
    return "And so am I!";
  }
  return `Hi! I'm a strict mode function! ${nested()}`;
}
function myNotStrictFunction() {
  return "I'm not strict.";
}
0

Legacy octal literals

Strict mode forbids a

class C1 {
  // All code here is evaluated in strict mode
  test() {
    delete Object.prototype;
  }
}
new C1().test(); // TypeError, because test() is in strict mode

const C2 = class {
  // All code here is evaluated in strict mode
};

// Code here may not be in strict mode
delete Object.prototype; // Will not throw error
2-prefixed octal literal or octal escape sequence. In sloppy mode, a number beginning with a
class C1 {
  // All code here is evaluated in strict mode
  test() {
    delete Object.prototype;
  }
}
new C1().test(); // TypeError, because test() is in strict mode

const C2 = class {
  // All code here is evaluated in strict mode
};

// Code here may not be in strict mode
delete Object.prototype; // Will not throw error
2, such as
class C1 {
  // All code here is evaluated in strict mode
  test() {
    delete Object.prototype;
  }
}
new C1().test(); // TypeError, because test() is in strict mode

const C2 = class {
  // All code here is evaluated in strict mode
};

// Code here may not be in strict mode
delete Object.prototype; // Will not throw error
4, is interpreted as an octal number (
class C1 {
  // All code here is evaluated in strict mode
  test() {
    delete Object.prototype;
  }
}
new C1().test(); // TypeError, because test() is in strict mode

const C2 = class {
  // All code here is evaluated in strict mode
};

// Code here may not be in strict mode
delete Object.prototype; // Will not throw error
5), if all digits are smaller than 8. Novice developers sometimes believe a leading-zero prefix has no semantic meaning, so they might use it as an alignment device — but this changes the number's meaning! A leading-zero syntax for the octal is rarely useful and can be mistakenly used, so strict mode makes it a syntax error:

function myStrictFunction() {
  // Function-level strict mode syntax
  "use strict";
  function nested() {
    return "And so am I!";
  }
  return `Hi! I'm a strict mode function! ${nested()}`;
}
function myNotStrictFunction() {
  return "I'm not strict.";
}
1

The standardized way to denote octal literals is via the

class C1 {
  // All code here is evaluated in strict mode
  test() {
    delete Object.prototype;
  }
}
new C1().test(); // TypeError, because test() is in strict mode

const C2 = class {
  // All code here is evaluated in strict mode
};

// Code here may not be in strict mode
delete Object.prototype; // Will not throw error
6 prefix. For example:

function myStrictFunction() {
  // Function-level strict mode syntax
  "use strict";
  function nested() {
    return "And so am I!";
  }
  return `Hi! I'm a strict mode function! ${nested()}`;
}
function myNotStrictFunction() {
  return "I'm not strict.";
}
2

Octal escape sequences, such as

class C1 {
  // All code here is evaluated in strict mode
  test() {
    delete Object.prototype;
  }
}
new C1().test(); // TypeError, because test() is in strict mode

const C2 = class {
  // All code here is evaluated in strict mode
};

// Code here may not be in strict mode
delete Object.prototype; // Will not throw error
7, which is equal to
class C1 {
  // All code here is evaluated in strict mode
  test() {
    delete Object.prototype;
  }
}
new C1().test(); // TypeError, because test() is in strict mode

const C2 = class {
  // All code here is evaluated in strict mode
};

// Code here may not be in strict mode
delete Object.prototype; // Will not throw error
8, can be used to represent characters by extended-ASCII character code numbers in octal. In strict mode, this is a syntax error. More formally, it's disallowed to have
class C1 {
  // All code here is evaluated in strict mode
  test() {
    delete Object.prototype;
  }
}
new C1().test(); // TypeError, because test() is in strict mode

const C2 = class {
  // All code here is evaluated in strict mode
};

// Code here may not be in strict mode
delete Object.prototype; // Will not throw error
9 followed by any decimal digit other than
class C1 {
  // All code here is evaluated in strict mode
  test() {
    delete Object.prototype;
  }
}
new C1().test(); // TypeError, because test() is in strict mode

const C2 = class {
  // All code here is evaluated in strict mode
};

// Code here may not be in strict mode
delete Object.prototype; // Will not throw error
2, or
"use strict";
let mistypeVariable;

// Assuming no global variable mistypeVarible exists
// this line throws a ReferenceError due to the
// misspelling of "mistypeVariable" (lack of an "a")
mistypeVarible = 17;
1 followed by a decimal digit; for example
"use strict";
let mistypeVariable;

// Assuming no global variable mistypeVarible exists
// this line throws a ReferenceError due to the
// misspelling of "mistypeVariable" (lack of an "a")
mistypeVarible = 17;
2 and
"use strict";
let mistypeVariable;

// Assuming no global variable mistypeVarible exists
// this line throws a ReferenceError due to the
// misspelling of "mistypeVariable" (lack of an "a")
mistypeVarible = 17;
3.

Setting properties on primitive values

Strict mode forbids setting properties on primitive values. Accessing a property on a primitive implicitly creates a wrapper object that's unobservable, so in sloppy mode, setting properties is ignored (no-op). In strict mode, a

"use strict";
let mistypeVariable;

// Assuming no global variable mistypeVarible exists
// this line throws a ReferenceError due to the
// misspelling of "mistypeVariable" (lack of an "a")
mistypeVarible = 17;
4 is thrown.

function myStrictFunction() {
  // Function-level strict mode syntax
  "use strict";
  function nested() {
    return "And so am I!";
  }
  return `Hi! I'm a strict mode function! ${nested()}`;
}
function myNotStrictFunction() {
  return "I'm not strict.";
}
3

Duplicate property names

Duplicate property names used to be considered a

"use strict";
let mistypeVariable;

// Assuming no global variable mistypeVarible exists
// this line throws a ReferenceError due to the
// misspelling of "mistypeVariable" (lack of an "a")
mistypeVarible = 17;
5 in strict mode. With the introduction of computed property names, making duplication possible at runtime, this restriction was removed in ES2015.

function myStrictFunction() {
  // Function-level strict mode syntax
  "use strict";
  function nested() {
    return "And so am I!";
  }
  return `Hi! I'm a strict mode function! ${nested()}`;
}
function myNotStrictFunction() {
  return "I'm not strict.";
}
4

Note: Making code that used to error become non-errors is always considered backwards-compatible. This is a good part of the language being strict about throwing errors: it leaves room for future semantic changes.

Strict mode simplifies how variable names map to particular variable definitions in the code. Many compiler optimizations rely on the ability to say that variable X is stored in that location: this is critical to fully optimizing JavaScript code. JavaScript sometimes makes this basic mapping of name to variable definition in the code impossible to perform until runtime. Strict mode removes most cases where this happens, so the compiler can better optimize strict mode code.

Removal of the with statement

Strict mode prohibits

"use strict";
let mistypeVariable;

// Assuming no global variable mistypeVarible exists
// this line throws a ReferenceError due to the
// misspelling of "mistypeVariable" (lack of an "a")
mistypeVarible = 17;
6. The problem with
"use strict";
let mistypeVariable;

// Assuming no global variable mistypeVarible exists
// this line throws a ReferenceError due to the
// misspelling of "mistypeVariable" (lack of an "a")
mistypeVarible = 17;
6 is that any name inside the block might map either to a property of the object passed to it, or to a variable in surrounding (or even global) scope, at runtime; it's impossible to know which beforehand. Strict mode makes
"use strict";
let mistypeVariable;

// Assuming no global variable mistypeVarible exists
// this line throws a ReferenceError due to the
// misspelling of "mistypeVariable" (lack of an "a")
mistypeVarible = 17;
6 a syntax error, so there's no chance for a name in a
"use strict";
let mistypeVariable;

// Assuming no global variable mistypeVarible exists
// this line throws a ReferenceError due to the
// misspelling of "mistypeVariable" (lack of an "a")
mistypeVarible = 17;
6 to refer to an unknown location at runtime:

function myStrictFunction() {
  // Function-level strict mode syntax
  "use strict";
  function nested() {
    return "And so am I!";
  }
  return `Hi! I'm a strict mode function! ${nested()}`;
}
function myNotStrictFunction() {
  return "I'm not strict.";
}
5

The simple alternative of assigning the object to a short name variable, then accessing the corresponding property on that variable, stands ready to replace

"use strict";
let mistypeVariable;

// Assuming no global variable mistypeVarible exists
// this line throws a ReferenceError due to the
// misspelling of "mistypeVariable" (lack of an "a")
mistypeVarible = 17;
6.

Non-leaking eval

In strict mode,

function sum(a = 1, b = 2) {
  // SyntaxError: "use strict" not allowed in function with default parameter
  "use strict";
  return a + b;
}
3 does not introduce new variables into the surrounding scope. In sloppy mode,
"use strict";

// Assignment to a non-writable global
var undefined = 5; // TypeError
var Infinity = 5; // TypeError

// Assignment to a non-writable property
const obj1 = {};
Object.defineProperty(obj1, "x", { value: 42, writable: false });
obj1.x = 9; // TypeError

// Assignment to a getter-only property
const obj2 = {
  get x() {
    return 17;
  },
};
obj2.x = 5; // TypeError

// Assignment to a new property on a non-extensible object
const fixed = {};
Object.preventExtensions(fixed);
fixed.newProp = "ohai"; // TypeError
2 introduces a variable
"use strict";

// Assignment to a non-writable global
var undefined = 5; // TypeError
var Infinity = 5; // TypeError

// Assignment to a non-writable property
const obj1 = {};
Object.defineProperty(obj1, "x", { value: 42, writable: false });
obj1.x = 9; // TypeError

// Assignment to a getter-only property
const obj2 = {
  get x() {
    return 17;
  },
};
obj2.x = 5; // TypeError

// Assignment to a new property on a non-extensible object
const fixed = {};
Object.preventExtensions(fixed);
fixed.newProp = "ohai"; // TypeError
3 into the surrounding function or the global scope. This means that, in general, in a function containing a call to
function sum(a = 1, b = 2) {
  // SyntaxError: "use strict" not allowed in function with default parameter
  "use strict";
  return a + b;
}
3, every name not referring to an argument or local variable must be mapped to a particular definition at runtime (because that
function sum(a = 1, b = 2) {
  // SyntaxError: "use strict" not allowed in function with default parameter
  "use strict";
  return a + b;
}
3 might have introduced a new variable that would hide the outer variable). In strict mode,
function sum(a = 1, b = 2) {
  // SyntaxError: "use strict" not allowed in function with default parameter
  "use strict";
  return a + b;
}
3 creates variables only for the code being evaluated, so
function sum(a = 1, b = 2) {
  // SyntaxError: "use strict" not allowed in function with default parameter
  "use strict";
  return a + b;
}
3 can't affect whether a name refers to an outer variable or some local variable:

function myStrictFunction() {
  // Function-level strict mode syntax
  "use strict";
  function nested() {
    return "And so am I!";
  }
  return `Hi! I'm a strict mode function! ${nested()}`;
}
function myNotStrictFunction() {
  return "I'm not strict.";
}
6

Whether the string passed to

"use strict";

// Assignment to a non-writable global
var undefined = 5; // TypeError
var Infinity = 5; // TypeError

// Assignment to a non-writable property
const obj1 = {};
Object.defineProperty(obj1, "x", { value: 42, writable: false });
obj1.x = 9; // TypeError

// Assignment to a getter-only property
const obj2 = {
  get x() {
    return 17;
  },
};
obj2.x = 5; // TypeError

// Assignment to a new property on a non-extensible object
const fixed = {};
Object.preventExtensions(fixed);
fixed.newProp = "ohai"; // TypeError
8 is evaluated in strict mode depends on how
"use strict";

// Assignment to a non-writable global
var undefined = 5; // TypeError
var Infinity = 5; // TypeError

// Assignment to a non-writable property
const obj1 = {};
Object.defineProperty(obj1, "x", { value: 42, writable: false });
obj1.x = 9; // TypeError

// Assignment to a getter-only property
const obj2 = {
  get x() {
    return 17;
  },
};
obj2.x = 5; // TypeError

// Assignment to a new property on a non-extensible object
const fixed = {};
Object.preventExtensions(fixed);
fixed.newProp = "ohai"; // TypeError
8 is invoked ().

Block-scoped function declarations

The JavaScript language specification, since its start, had not allowed function declarations nested in block statements. However, it was so intuitive that most browsers implemented it as an extension grammar. Unfortunately, the implementations' semantics diverged, and it became impossible for the language specification to reconcile all implementations. Therefore, are only explicitly specified in strict mode (whereas they were once disallowed in strict mode), while sloppy mode behavior remains divergent among browsers.

Strict mode makes

function myStrictFunction() {
  // because this is a module, I'm strict by default
}
export default myStrictFunction;
3 and
function sum(a = 1, b = 2) {
  // SyntaxError: "use strict" not allowed in function with default parameter
  "use strict";
  return a + b;
}
3 less bizarrely magical. Both involve a considerable amount of magical behavior in sloppy mode:
function sum(a = 1, b = 2) {
  // SyntaxError: "use strict" not allowed in function with default parameter
  "use strict";
  return a + b;
}
3 to add or remove bindings and to change binding values, and
function myStrictFunction() {
  // because this is a module, I'm strict by default
}
export default myStrictFunction;
3 syncing named arguments with its indexed properties. Strict mode makes great strides toward treating
function sum(a = 1, b = 2) {
  // SyntaxError: "use strict" not allowed in function with default parameter
  "use strict";
  return a + b;
}
3 and
function myStrictFunction() {
  // because this is a module, I'm strict by default
}
export default myStrictFunction;
3 as keywords.

Preventing binding or assigning eval and arguments

The names

function sum(a = 1, b = 2) {
  // SyntaxError: "use strict" not allowed in function with default parameter
  "use strict";
  return a + b;
}
3 and
function myStrictFunction() {
  // because this is a module, I'm strict by default
}
export default myStrictFunction;
3 can't be bound or assigned in language syntax. All these attempts to do so are syntax errors:

function myStrictFunction() {
  // Function-level strict mode syntax
  "use strict";
  function nested() {
    return "And so am I!";
  }
  return `Hi! I'm a strict mode function! ${nested()}`;
}
function myNotStrictFunction() {
  return "I'm not strict.";
}
7

No syncing between parameters and arguments indices

Strict mode code doesn't sync indices of the

function myStrictFunction() {
  // because this is a module, I'm strict by default
}
export default myStrictFunction;
3 object with each parameter binding. In a sloppy mode function whose first argument is
"use strict";
delete Object.prototype; // TypeError
delete [].length; // TypeError
9, setting
"use strict";
delete Object.prototype; // TypeError
delete [].length; // TypeError
9 also sets
"use strict";

var x;
delete x; // syntax error
1, and vice versa (unless no arguments were provided or
"use strict";

var x;
delete x; // syntax error
1 is deleted).
function myStrictFunction() {
  // because this is a module, I'm strict by default
}
export default myStrictFunction;
3 objects for strict mode functions store the original arguments when the function was invoked.
"use strict";

var x;
delete x; // syntax error
4 does not track the value of the corresponding named argument, nor does a named argument track the value in the corresponding
"use strict";

var x;
delete x; // syntax error
4.

function myStrictFunction() {
  // Function-level strict mode syntax
  "use strict";
  function nested() {
    return "And so am I!";
  }
  return `Hi! I'm a strict mode function! ${nested()}`;
}
function myNotStrictFunction() {
  return "I'm not strict.";
}
8

Strict mode makes it easier to write "secure" JavaScript. Some websites now provide ways for users to write JavaScript which will be run by the website on behalf of other users. JavaScript in browsers can access the user's private information, so such JavaScript must be partially transformed before it is run, to censor access to forbidden functionality. JavaScript's flexibility makes it effectively impossible to do this without many runtime checks. Certain language functions are so pervasive that performing runtime checks has a considerable performance cost. A few strict mode tweaks, plus requiring that user-submitted JavaScript be strict mode code and that it be invoked in a certain manner, substantially reduce the need for those runtime checks.

No this substitution

The value passed as

"use strict";

var x;
delete x; // syntax error
6 to a function in strict mode is not forced into being an object (a.k.a. "boxed"). For a sloppy mode function,
"use strict";

var x;
delete x; // syntax error
6 is always an object: either the provided object, if called with an object-valued
"use strict";

var x;
delete x; // syntax error
6; or the boxed value of
"use strict";

var x;
delete x; // syntax error
6, if called with a primitive as
"use strict";

var x;
delete x; // syntax error
6; or the global object, if called with
"use strict";

delete globalThis.x;
1 or
"use strict";

delete globalThis.x;
2 as
"use strict";

var x;
delete x; // syntax error
6. (Use
"use strict";

delete globalThis.x;
4,
"use strict";

delete globalThis.x;
5, or
"use strict";

delete globalThis.x;
6 to specify a particular
"use strict";

var x;
delete x; // syntax error
6.) Not only is automatic boxing a performance cost, but exposing the global object in browsers is a security hazard because the global object provides access to functionality that "secure" JavaScript environments must restrict. Thus for a strict mode function, the specified
"use strict";

var x;
delete x; // syntax error
6 is not boxed into an object, and if unspecified,
"use strict";

var x;
delete x; // syntax error
6 is
"use strict";

delete globalThis.x;
1 instead of
class C1 {
  // All code here is evaluated in strict mode
  test() {
    delete Object.prototype;
  }
}
new C1().test(); // TypeError, because test() is in strict mode

const C2 = class {
  // All code here is evaluated in strict mode
};

// Code here may not be in strict mode
delete Object.prototype; // Will not throw error
0:

function myStrictFunction() {
  // Function-level strict mode syntax
  "use strict";
  function nested() {
    return "And so am I!";
  }
  return `Hi! I'm a strict mode function! ${nested()}`;
}
function myNotStrictFunction() {
  return "I'm not strict.";
}
9

Removal of stack-walking properties

In strict mode it's no longer possible to "walk" the JavaScript stack. Many implementations used to implement some extension features that make it possible to detect the upstream caller of a function. When a function

function myStrictFunction() {
  // Function-level strict mode syntax
  "use strict";
  function nested() {
    return "And so am I!";
  }
  return `Hi! I'm a strict mode function! ${nested()}`;
}
function myNotStrictFunction() {
  return "I'm not strict.";
}
02 is in the middle of being called,
function myStrictFunction() {
  // Function-level strict mode syntax
  "use strict";
  function nested() {
    return "And so am I!";
  }
  return `Hi! I'm a strict mode function! ${nested()}`;
}
function myNotStrictFunction() {
  return "I'm not strict.";
}
03 is the function that most recently called
function myStrictFunction() {
  // Function-level strict mode syntax
  "use strict";
  function nested() {
    return "And so am I!";
  }
  return `Hi! I'm a strict mode function! ${nested()}`;
}
function myNotStrictFunction() {
  return "I'm not strict.";
}
02, and
function myStrictFunction() {
  // Function-level strict mode syntax
  "use strict";
  function nested() {
    return "And so am I!";
  }
  return `Hi! I'm a strict mode function! ${nested()}`;
}
function myNotStrictFunction() {
  return "I'm not strict.";
}
05 is the
function myStrictFunction() {
  // because this is a module, I'm strict by default
}
export default myStrictFunction;
3 for that invocation of
function myStrictFunction() {
  // Function-level strict mode syntax
  "use strict";
  function nested() {
    return "And so am I!";
  }
  return `Hi! I'm a strict mode function! ${nested()}`;
}
function myNotStrictFunction() {
  return "I'm not strict.";
}
02. Both extensions are problematic for "secure" JavaScript because they allow "secured" code to access "privileged" functions and their (potentially unsecured) arguments. If
function myStrictFunction() {
  // Function-level strict mode syntax
  "use strict";
  function nested() {
    return "And so am I!";
  }
  return `Hi! I'm a strict mode function! ${nested()}`;
}
function myNotStrictFunction() {
  return "I'm not strict.";
}
02 is in strict mode, both
function myStrictFunction() {
  // Function-level strict mode syntax
  "use strict";
  function nested() {
    return "And so am I!";
  }
  return `Hi! I'm a strict mode function! ${nested()}`;
}
function myNotStrictFunction() {
  return "I'm not strict.";
}
03 and
function myStrictFunction() {
  // Function-level strict mode syntax
  "use strict";
  function nested() {
    return "And so am I!";
  }
  return `Hi! I'm a strict mode function! ${nested()}`;
}
function myNotStrictFunction() {
  return "I'm not strict.";
}
05 are non-deletable properties which throw when set or retrieved:

function sum(a = 1, b = 2) {
  // SyntaxError: "use strict" not allowed in function with default parameter
  "use strict";
  return a + b;
}
0

Similarly,

function myStrictFunction() {
  // Function-level strict mode syntax
  "use strict";
  function nested() {
    return "And so am I!";
  }
  return `Hi! I'm a strict mode function! ${nested()}`;
}
function myNotStrictFunction() {
  return "I'm not strict.";
}
11 is no longer supported. In sloppy mode,
function myStrictFunction() {
  // Function-level strict mode syntax
  "use strict";
  function nested() {
    return "And so am I!";
  }
  return `Hi! I'm a strict mode function! ${nested()}`;
}
function myNotStrictFunction() {
  return "I'm not strict.";
}
11 refers to the enclosing function. This use case is weak: name the enclosing function! Moreover,
function myStrictFunction() {
  // Function-level strict mode syntax
  "use strict";
  function nested() {
    return "And so am I!";
  }
  return `Hi! I'm a strict mode function! ${nested()}`;
}
function myNotStrictFunction() {
  return "I'm not strict.";
}
11 substantially hinders optimizations like inlining functions, because it must be made possible to provide a reference to the un-inlined function if
function myStrictFunction() {
  // Function-level strict mode syntax
  "use strict";
  function nested() {
    return "And so am I!";
  }
  return `Hi! I'm a strict mode function! ${nested()}`;
}
function myNotStrictFunction() {
  return "I'm not strict.";
}
11 is accessed.
function myStrictFunction() {
  // Function-level strict mode syntax
  "use strict";
  function nested() {
    return "And so am I!";
  }
  return `Hi! I'm a strict mode function! ${nested()}`;
}
function myNotStrictFunction() {
  return "I'm not strict.";
}
11 for strict mode functions is a non-deletable property which throws an error when set or retrieved:

function sum(a = 1, b = 2) {
  // SyntaxError: "use strict" not allowed in function with default parameter
  "use strict";
  return a + b;
}
1

Extra reserved words

are identifiers that can't be used as variable names. Strict mode reserves some more names than sloppy mode, some of which are already used in the language, and some of which are reserved for the future to make future syntax extensions easier to implement.

  • function myStrictFunction() {
      // Function-level strict mode syntax
      "use strict";
      function nested() {
        return "And so am I!";
      }
      return `Hi! I'm a strict mode function! ${nested()}`;
    }
    function myNotStrictFunction() {
      return "I'm not strict.";
    }
    
    16
  • function myStrictFunction() {
      // Function-level strict mode syntax
      "use strict";
      function nested() {
        return "And so am I!";
      }
      return `Hi! I'm a strict mode function! ${nested()}`;
    }
    function myNotStrictFunction() {
      return "I'm not strict.";
    }
    
    17
  • function myStrictFunction() {
      // Function-level strict mode syntax
      "use strict";
      function nested() {
        return "And so am I!";
      }
      return `Hi! I'm a strict mode function! ${nested()}`;
    }
    function myNotStrictFunction() {
      return "I'm not strict.";
    }
    
    18
  • function myStrictFunction() {
      // Function-level strict mode syntax
      "use strict";
      function nested() {
        return "And so am I!";
      }
      return `Hi! I'm a strict mode function! ${nested()}`;
    }
    function myNotStrictFunction() {
      return "I'm not strict.";
    }
    
    19
  • function myStrictFunction() {
      // Function-level strict mode syntax
      "use strict";
      function nested() {
        return "And so am I!";
      }
      return `Hi! I'm a strict mode function! ${nested()}`;
    }
    function myNotStrictFunction() {
      return "I'm not strict.";
    }
    
    20
  • function myStrictFunction() {
      // Function-level strict mode syntax
      "use strict";
      function nested() {
        return "And so am I!";
      }
      return `Hi! I'm a strict mode function! ${nested()}`;
    }
    function myNotStrictFunction() {
      return "I'm not strict.";
    }
    
    21
  • function myStrictFunction() {
      // Function-level strict mode syntax
      "use strict";
      function nested() {
        return "And so am I!";
      }
      return `Hi! I'm a strict mode function! ${nested()}`;
    }
    function myNotStrictFunction() {
      return "I'm not strict.";
    }
    
    22
  • function myStrictFunction() {
      // Function-level strict mode syntax
      "use strict";
      function nested() {
        return "And so am I!";
      }
      return `Hi! I'm a strict mode function! ${nested()}`;
    }
    function myNotStrictFunction() {
      return "I'm not strict.";
    }
    
    23
  • function myStrictFunction() {
      // Function-level strict mode syntax
      "use strict";
      function nested() {
        return "And so am I!";
      }
      return `Hi! I'm a strict mode function! ${nested()}`;
    }
    function myNotStrictFunction() {
      return "I'm not strict.";
    }
    
    24

Strict mode has been designed so that the transition to it can be made gradually. It is possible to change each file individually and even to transition code to strict mode down to the function granularity.

You can migrate a codebase to strict mode by first adding

function myStrictFunction() {
  // because this is a module, I'm strict by default
}
export default myStrictFunction;
0 to a piece of source code, and then fixing all execution errors, while watching out for semantic differences.

When adding

function sum(a = 1, b = 2) {
  // SyntaxError: "use strict" not allowed in function with default parameter
  "use strict";
  return a + b;
}
7, the following cases will throw a
"use strict";
let mistypeVariable;

// Assuming no global variable mistypeVarible exists
// this line throws a ReferenceError due to the
// misspelling of "mistypeVariable" (lack of an "a")
mistypeVarible = 17;
5 before the script is executing:

  • Octal syntax
    function myStrictFunction() {
      // Function-level strict mode syntax
      "use strict";
      function nested() {
        return "And so am I!";
      }
      return `Hi! I'm a strict mode function! ${nested()}`;
    }
    function myNotStrictFunction() {
      return "I'm not strict.";
    }
    
    28
  • "use strict";
    let mistypeVariable;
    
    // Assuming no global variable mistypeVarible exists
    // this line throws a ReferenceError due to the
    // misspelling of "mistypeVariable" (lack of an "a")
    mistypeVarible = 17;
    
    6 statement
  • Using
    function myStrictFunction() {
      // Function-level strict mode syntax
      "use strict";
      function nested() {
        return "And so am I!";
      }
      return `Hi! I'm a strict mode function! ${nested()}`;
    }
    function myNotStrictFunction() {
      return "I'm not strict.";
    }
    
    30 on a variable name
    function myStrictFunction() {
      // Function-level strict mode syntax
      "use strict";
      function nested() {
        return "And so am I!";
      }
      return `Hi! I'm a strict mode function! ${nested()}`;
    }
    function myNotStrictFunction() {
      return "I'm not strict.";
    }
    
    31;
  • Using
    function sum(a = 1, b = 2) {
      // SyntaxError: "use strict" not allowed in function with default parameter
      "use strict";
      return a + b;
    }
    
    3 or
    function myStrictFunction() {
      // because this is a module, I'm strict by default
    }
    export default myStrictFunction;
    
    3 as variable or function argument name
  • Using one of the newly (in prevision for future language features):
    function myStrictFunction() {
      // Function-level strict mode syntax
      "use strict";
      function nested() {
        return "And so am I!";
      }
      return `Hi! I'm a strict mode function! ${nested()}`;
    }
    function myNotStrictFunction() {
      return "I'm not strict.";
    }
    
    16,
    function myStrictFunction() {
      // Function-level strict mode syntax
      "use strict";
      function nested() {
        return "And so am I!";
      }
      return `Hi! I'm a strict mode function! ${nested()}`;
    }
    function myNotStrictFunction() {
      return "I'm not strict.";
    }
    
    17,
    function myStrictFunction() {
      // Function-level strict mode syntax
      "use strict";
      function nested() {
        return "And so am I!";
      }
      return `Hi! I'm a strict mode function! ${nested()}`;
    }
    function myNotStrictFunction() {
      return "I'm not strict.";
    }
    
    18,
    function myStrictFunction() {
      // Function-level strict mode syntax
      "use strict";
      function nested() {
        return "And so am I!";
      }
      return `Hi! I'm a strict mode function! ${nested()}`;
    }
    function myNotStrictFunction() {
      return "I'm not strict.";
    }
    
    19,
    function myStrictFunction() {
      // Function-level strict mode syntax
      "use strict";
      function nested() {
        return "And so am I!";
      }
      return `Hi! I'm a strict mode function! ${nested()}`;
    }
    function myNotStrictFunction() {
      return "I'm not strict.";
    }
    
    20,
    function myStrictFunction() {
      // Function-level strict mode syntax
      "use strict";
      function nested() {
        return "And so am I!";
      }
      return `Hi! I'm a strict mode function! ${nested()}`;
    }
    function myNotStrictFunction() {
      return "I'm not strict.";
    }
    
    21,
    function myStrictFunction() {
      // Function-level strict mode syntax
      "use strict";
      function nested() {
        return "And so am I!";
      }
      return `Hi! I'm a strict mode function! ${nested()}`;
    }
    function myNotStrictFunction() {
      return "I'm not strict.";
    }
    
    22,
    function myStrictFunction() {
      // Function-level strict mode syntax
      "use strict";
      function nested() {
        return "And so am I!";
      }
      return `Hi! I'm a strict mode function! ${nested()}`;
    }
    function myNotStrictFunction() {
      return "I'm not strict.";
    }
    
    23, and
    function myStrictFunction() {
      // Function-level strict mode syntax
      "use strict";
      function nested() {
        return "And so am I!";
      }
      return `Hi! I'm a strict mode function! ${nested()}`;
    }
    function myNotStrictFunction() {
      return "I'm not strict.";
    }
    
    24
  • Declaring two function parameters with the same name
    function myStrictFunction() {
      // Function-level strict mode syntax
      "use strict";
      function nested() {
        return "And so am I!";
      }
      return `Hi! I'm a strict mode function! ${nested()}`;
    }
    function myNotStrictFunction() {
      return "I'm not strict.";
    }
    
    43
  • Declaring the same property name twice in an object literal
    function myStrictFunction() {
      // Function-level strict mode syntax
      "use strict";
      function nested() {
        return "And so am I!";
      }
      return `Hi! I'm a strict mode function! ${nested()}`;
    }
    function myNotStrictFunction() {
      return "I'm not strict.";
    }
    
    44. This constraint was later removed (bug 1041128).

These errors are good, because they reveal plain errors or bad practices. They occur before the code is running, so they are easily discoverable as long as the code gets parsed by the runtime.

JavaScript used to silently fail in contexts where what was done should be an error. Strict mode throws in such cases. If your code base contains such cases, testing will be necessary to be sure nothing is broken. You can screen for such errors at the function granularity level.

  • Assigning to an undeclared variable throws a
    function myStrictFunction() {
      // Function-level strict mode syntax
      "use strict";
      function nested() {
        return "And so am I!";
      }
      return `Hi! I'm a strict mode function! ${nested()}`;
    }
    function myNotStrictFunction() {
      return "I'm not strict.";
    }
    
    45. This used to set a property on the global object, which is rarely the expected effect. If you really want to set a value to the global object, explicitly assign it as a property on
    class C1 {
      // All code here is evaluated in strict mode
      test() {
        delete Object.prototype;
      }
    }
    new C1().test(); // TypeError, because test() is in strict mode
    
    const C2 = class {
      // All code here is evaluated in strict mode
    };
    
    // Code here may not be in strict mode
    delete Object.prototype; // Will not throw error
    
    0.
  • Failing to assign to an object's property (e.g. it's read-only) throws a
    "use strict";
    let mistypeVariable;
    
    // Assuming no global variable mistypeVarible exists
    // this line throws a ReferenceError due to the
    // misspelling of "mistypeVariable" (lack of an "a")
    mistypeVarible = 17;
    
    4. In sloppy mode, this would silently fail.
  • Deleting a non-deletable property throws a
    "use strict";
    let mistypeVariable;
    
    // Assuming no global variable mistypeVarible exists
    // this line throws a ReferenceError due to the
    // misspelling of "mistypeVariable" (lack of an "a")
    mistypeVarible = 17;
    
    4. In sloppy mode, this would silently fail.
  • Accessing
    function myStrictFunction() {
      // Function-level strict mode syntax
      "use strict";
      function nested() {
        return "And so am I!";
      }
      return `Hi! I'm a strict mode function! ${nested()}`;
    }
    function myNotStrictFunction() {
      return "I'm not strict.";
    }
    
    11,
    function myStrictFunction() {
      // Function-level strict mode syntax
      "use strict";
      function nested() {
        return "And so am I!";
      }
      return `Hi! I'm a strict mode function! ${nested()}`;
    }
    function myNotStrictFunction() {
      return "I'm not strict.";
    }
    
    50, or
    function myStrictFunction() {
      // Function-level strict mode syntax
      "use strict";
      function nested() {
        return "And so am I!";
      }
      return `Hi! I'm a strict mode function! ${nested()}`;
    }
    function myNotStrictFunction() {
      return "I'm not strict.";
    }
    
    51 throws a
    "use strict";
    let mistypeVariable;
    
    // Assuming no global variable mistypeVarible exists
    // this line throws a ReferenceError due to the
    // misspelling of "mistypeVariable" (lack of an "a")
    mistypeVarible = 17;
    
    4 if the function is in strict mode. If you are using
    function myStrictFunction() {
      // Function-level strict mode syntax
      "use strict";
      function nested() {
        return "And so am I!";
      }
      return `Hi! I'm a strict mode function! ${nested()}`;
    }
    function myNotStrictFunction() {
      return "I'm not strict.";
    }
    
    11 to call the function recursively, you can use a named function expression instead.

These differences are very subtle differences. It's possible that a test suite doesn't catch this kind of subtle difference. Careful review of your code base will probably be necessary to be sure these differences don't affect the semantics of your code. Fortunately, this careful review can be done gradually down the function granularity.

"use strict";

var x;
delete x; // syntax error
6

In sloppy mode, function calls like

function myStrictFunction() {
  // Function-level strict mode syntax
  "use strict";
  function nested() {
    return "And so am I!";
  }
  return `Hi! I'm a strict mode function! ${nested()}`;
}
function myNotStrictFunction() {
  return "I'm not strict.";
}
55 would pass the global object as the
"use strict";

var x;
delete x; // syntax error
6 value. In strict mode, it is now
"use strict";

delete globalThis.x;
1. When a function was called with
"use strict";

delete globalThis.x;
4 or
"use strict";

delete globalThis.x;
5, if the value was a primitive value, this one was boxed into an object (or the global object for
"use strict";

delete globalThis.x;
1 and
"use strict";

delete globalThis.x;
2). In strict mode, the value is passed directly without conversion or replacement.

function myStrictFunction() {
  // because this is a module, I'm strict by default
}
export default myStrictFunction;
3

In sloppy mode, modifying a value in the

function myStrictFunction() {
  // because this is a module, I'm strict by default
}
export default myStrictFunction;
3 object modifies the corresponding named argument. This made optimizations complicated for JavaScript engine and made code harder to read/understand. In strict mode, the
function myStrictFunction() {
  // because this is a module, I'm strict by default
}
export default myStrictFunction;
3 object is created and initialized with the same values than the named arguments, but changes to either the
function myStrictFunction() {
  // because this is a module, I'm strict by default
}
export default myStrictFunction;
3 object or the named arguments aren't reflected in one another.

function sum(a = 1, b = 2) {
  // SyntaxError: "use strict" not allowed in function with default parameter
  "use strict";
  return a + b;
}
3

In strict mode code,

function sum(a = 1, b = 2) {
  // SyntaxError: "use strict" not allowed in function with default parameter
  "use strict";
  return a + b;
}
3 doesn't create a new variable in the scope from which it was called. Also, of course, in strict mode, the string is evaluated with strict mode rules. Thorough testing will need to be performed to make sure nothing breaks. Not using eval if you don't really need it may be another pragmatic solution.

Block-scoped function declarations

In sloppy mode, a function declaration inside a block may be visible outside the block and even callable. In strict mode, a function declaration inside a block is only visible inside the block.

Which of the following statements is not true for a function?

Answer and Explanation: The statement that is not true is c; ''If the domain of a function consists of more than one element, then the range must also consist of more than one element.

Which of the following statements about function is true?

1 Answer. Correct option - (A) An invoking function must pass arguments to the invoked function. An invoking function must pass arguments to the invoked function.

Which of the following statements are true about a function in programming?

The correct answer is Functions are reusable pieces of programs. Explanation: The correct statement is that Functions are reusable pieces of programs.

Which statement among the following is used to come out of the function?

The Return statement simultaneously assigns the return value and exits the function, as the following example shows.