Thanks. I've just filed it to bugs.ecmascript.org https://bugs.ecmascript.org/show_bug.cgi?id=1119
It appears to me that the best fix is in the evaluation semantics of > FunctionBody. Looks nice to me too. On Wed, Dec 5, 2012 at 3:15 AM, Allen Wirfs-Brock <[email protected]>wrote: > (Note that this is probably the sort of issue that would be better to > report to bugs.ecmascript.org) > > Yes, that looks like an issue. It appears to me that the best fix is in > the evaluation semantics of FunctionBody. It should take care of Return > completions and also make sure that normal completions yield undefined and > not empty. > > Letting Return completions escape from functions was needed when we were > considering supporting block lambdas but isn't need now. > > Allen > > > > > > On Dec 3, 2012, at 11:23 PM, Yusuke Suzuki wrote: > > Hello all, > > Because of 8.3.19.1 step 17, [[Call]] returns result completion even if > result.type isn't return. > As the result, [[Call]] may return NormalCompletion(empty), is it expected > behavior? > I think we should change empty to undefined. > > For example, > > function test() { > var i; > } > var value = test(); // value is empty... > > -- > Regards, > Yusuke Suzuki > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > > > -- Regards, Yusuke Suzuki
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
