André Bargull (2014-01-09T01:54:31.000Z)
> Thanks for the reply.
>
> I'd actually expect `undefined` because function declarations does not
> return anything. Converting it to a function expression kind of misses the
> point since those are well... expressions :)
>
> I've tried looking in all the relevant places in the spec but still
> couldn't unambiguously figure out which browser is 'correct'.

There are a few edge cases in reference resolution which are not 
correctly implemented in most browsers. Your example is basically the 
same as test case 2 from 
https://bugs.ecmascript.org/show_bug.cgi?id=1751. The relevant section 
in the specification is "12.13.4 Runtime Semantics: Evaluation": The 
left hand side of an assignment is always evaluated before the right 
hand side. This includes resolving and remembering the reference 
information for an identifier reference. In this case the identifier 
reference resolves to a binding on the global object, so assignment must 
be performed on the global, even if a (direct) eval expression 
introduces new bindings with the same name in the current scope.


- André
domenic at domenicdenicola.com (2014-01-14T17:54:01.419Z)
> Thanks for the reply.
>
> I'd actually expect `undefined` because function declarations does not
> return anything. Converting it to a function expression kind of misses the
> point since those are well... expressions :)
>
> I've tried looking in all the relevant places in the spec but still
> couldn't unambiguously figure out which browser is 'correct'.

There are a few edge cases in reference resolution which are not 
correctly implemented in most browsers. Your example is basically the 
same as test case 2 from 
https://bugs.ecmascript.org/show_bug.cgi?id=1751. The relevant section 
in the specification is "12.13.4 Runtime Semantics: Evaluation": The 
left hand side of an assignment is always evaluated before the right 
hand side. This includes resolving and remembering the reference 
information for an identifier reference. In this case the identifier 
reference resolves to a binding on the global object, so assignment must 
be performed on the global, even if a (direct) eval expression 
introduces new bindings with the same name in the current scope.