Allen Wirfs-Brock wrote:
On Sep 8, 2012, at 3:20 PM, Brendan Eich wrote:
SpiderMonkey (Firefox 15 and newer has default parameters):
js> function f(a = g) { function g(){}; return a; }
js> f()
function g(){}
So function g is hoisted and a defaults to it, as expected.
While I agree that the above is reasonable behavior. It wasn't the consensus
that was reach earlier this year at the Jan. (or may March??) meeting. What
we agreed upon is that default value expressions in parameter lists have
visibility to the left and upward in scope but do not have visibility of
anything declared within the curlies that surround the body. So, in the above
example, g should be a reference error when evaluated as a default value
initializer.
As the NOTE in step 9 of 10-5-3 says:
NOTE Binding Initialisation for formals is performed prior to
instantiating any non-parameter declarations in order to ensure that any such
local declarations are not visible to any parameter Initialisation code that
may be evaluated.
You're right, I had forgotten that.
Is it well-motivated other than in the naive left-to-right sense, which
function hoisting already violates? Perhaps, because parameters to the
right are not yet bound.
If so, then I can live with it, and g in the f(a = g) bit above would
use an outer g, if any (or throw on undefined g).
But this still does not mean the implicit |yield;| at entry to generator
function should be other than observably "after" parameter defaulting,
so that we get the throw at loc 1. Right?
IOW, this is a tangent, good to nail down (sorry for prying it up), but
not a crucial experiment for generator default parameter semantics.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
