8

This is a named function expression with the name test. Inside, I assign 123 to a variable, also named test. Then test is logged. The function prints its body in the console, but not 123. What is the reason for such behavior?

(function test() {
  test = 123;
  console.log( test );
}());

Where does my explanation of function execution fail?

  1. Start of function execution: test is a local variable that references the function itself
  2. Local variable test is reassigned to number 123
  3. console.log(test) shows the number 123.
Sebastian Simon
  • 18,263
  • 7
  • 55
  • 75
Roman Belyaev
  • 115
  • 4
  • 1
    http://stackoverflow.com/questions/6318835/javascript-hoisting-issue?rq=1 – micnic Jun 03 '14 at 17:36
  • 4
    I'm not sure we can consider this an exact duplicate. In this case there is an assignment, not simply `var test;` as in the linked question. – James Montagne Jun 03 '14 at 17:42
  • 1
    @dandavis If you still here, in the comment to Kodlee's answer you said "`the name of the function is a "var" to the function...`". In the same manner as arguments are declared? If that's the case, is the function name somehow protected then? You can change the value of arguments thought they are "pre-declared". – Teemu Jun 03 '14 at 17:51
  • 1
    @Teemu: i'm not sure exactly how the name works low-level. the function name is slightly special no doubt since it seems to resist direct clobbering, but i don't know about "protected"; you can still "var test=123;" inside the function, which makes sense. An ecmaScript spec check would probably explain the phenomenon we're experiencing. – dandavis Jun 03 '14 at 18:02
  • Possible duplicate of [Javascript - Hoisting Issue](https://stackoverflow.com/questions/6318835/javascript-hoisting-issue) – Murad Sofiyev Aug 17 '19 at 09:25

1 Answers1

5

I believe this piece of the ecma spec explains this behavior. This relates specifically to named Function Expressions

The production

FunctionExpression : function Identifier ( FormalParameterListopt ) { FunctionBody }

is evaluated as follows:

  1. Let funcEnv be the result of calling NewDeclarativeEnvironment passing the running execution context’s Lexical Environment as the argument
  2. Let envRec be funcEnv’s environment record.
  3. Call the CreateImmutableBinding concrete method of envRec passing the String value of Identifier as the argument.
  4. Let closure be the result of creating a new Function object as specified in 13.2 with parameters specified by FormalParameterListopt and body specified by FunctionBody. Pass in funcEnv as the Scope. Pass in true as the Strict flag if the FunctionExpression is contained in strict code or if its FunctionBody is strict code.
  5. Call the InitializeImmutableBinding concrete method of envRec passing the String value of Identifier and closure as the arguments.
  6. Return closure.

The use of CreateImmutableBinding when creating the scope of a named Function Expression, creates the identifier (in this case test) as an immutable variable. That is why assignment to it does not change its value.

Community
  • 1
  • 1
James Montagne
  • 77,516
  • 14
  • 110
  • 130
  • 2
    Related would be this discussion of why this is done http://stackoverflow.com/questions/15129504/why-are-anonymous-function-expressions-and-named-function-expressions-initialize – James Montagne Jun 03 '14 at 18:12
  • I wonder if the binding is immutable why this code doesn't throw in strict mode? `(function test() { "use strict"; test = 123; console.log( test); }())` – Yury Tarabanko Jun 03 '14 at 18:17
  • 1
    @YuryTarabanko: It *does* throw an `Unhandled Error: Invalid assignment in strict mode`. Maybe try `(function(){ "use strict"; (function test() { test = 123;}()); }())` – Bergi Jun 03 '14 at 18:18
  • OK, why this code would print `123` in console? `(function test() { var test = 123; console.log(test)}());` Does `CreateImmutableBinding` forbid only variable changing, but not variable redefinition? – Roman Belyaev Jun 03 '14 at 18:26
  • 4
    @RomanBelyaev Once you add `var` to your `test` you create a local `test` instead of trying to re-assign the immutable – James Montagne Jun 03 '14 at 18:27
  • 1
    @YuryTarabanko: That's indeed a bug in Chrome. They throw correctly when assigning to `arguments`. – Bergi Jun 03 '14 at 18:30
  • In the 9th edition of the ECMA-262 spec this behavior is in section [14.1.21 RS: Evaluation](http://www.ecma-international.org/ecma-262/9.0/index.html#sec-function-definitions-runtime-semantics-evaluation), in the 10th edition it currently is in [14.1.22 RS: Evaluation](http://www.ecma-international.org/ecma-262/#sec-function-definitions-runtime-semantics-evaluation). Should we update this answer to the current spec? – Sebastian Simon Aug 17 '19 at 17:45