Source: David Herman,
https://github.com/rwaldron/tc39-notes/blob/master/es6/2013-11/nov-20.md
Can someone elaborate? I don’t see an alternative.
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
In the most recent meeting notes, “async functions” were mentioned [1]
(keyword: `function!`). Is there a proposal somewhere? Is it the following one?
http://wiki.ecmascript.org/doku.php?id=strawman:deferred_functions
[1]
Lately I've been writing very processor heavy Javascript. I feel like it could
benefit a lot from having a syntax feature for removing debug statements.
Obviously JS is interpreted and not compiled, so I'm not sure if this sounds
completely unrealistic, but it has some very useful scenarios.
I
Le 28/11/2013 09:59, Brandon Andrews a écrit :
Lately I've been writing very processor heavy Javascript. I feel like it could
benefit a lot from having a syntax feature for removing debug statements.
Obviously JS is interpreted and not compiled, so I'm not sure if this sounds
completely
http://wiki.ecmascript.org/doku.php?id=strawman:async_functions
cheers, MarkM
On Nov 28, 2013 12:34 AM, Axel Rauschmayer a...@rauschma.de wrote:
In the most recent meeting notes, “async functions” were mentioned [1]
(keyword: `function!`). Is there a proposal somewhere? Is it the following
Thanks! But I don’t see `function!`, anywhere.
On Nov 28, 2013, at 16:10 , Mark S. Miller erig...@google.com wrote:
http://wiki.ecmascript.org/doku.php?id=strawman:async_functions
cheers, MarkM
On Nov 28, 2013 12:34 AM, Axel Rauschmayer a...@rauschma.de wrote:
In the most recent meeting
Both Closure Compiler and UglifyJS has something called defines which
allow you to override the value of a variable using a command line
parameter. Combining this with their dead code removal and you have a
preprocessor tool similar to #ifdefs.
On Nov 28, 2013, at 12:59 AM, Brandon Andrews warcraftthre...@sbcglobal.net
wrote:
Lately I've been writing very processor heavy Javascript. I feel like it
could benefit a lot from having a syntax feature for removing debug
statements. Obviously JS is interpreted and not compiled,
so
On Nov 27, 2013, at 7:29 PM, Paul Hoffman wrote:
no hat
On Nov 27, 2013, at 5:00 PM, Alex Russell slightly...@google.com wrote:
Will you also be citing ECMA-404 normatively to avoid this sort of
divergence in the future?
If you believe that ECMA-404 will change in the future, that
On 11/28/13 11:41 AM, Filip Pizlo wrote:
Here's why var is good enough provided that you do the var debug = false
thing at the top of the function:
I would think it would be done at window scope, or in some module scope,
not at the top of every function, no?
-Boris
function*(a = yield/b/g) {
a = yield/b/g;
}
Why allow yield as an identifier in parameter defaults of generators?
Wouldn't it be simpler just to disallow there as well?
___
es-discuss mailing list
es-discuss@mozilla.org
Kevin Smith wrote:
function*(a = yield/b/g) {
a = yield/b/g;
}
Why allow yield as an identifier in parameter defaults of generators?
Wouldn't it be simpler just to disallow there as well?
When proposing an irregularity, you need a better reason than why allow?
Parameter
On Nov 28, 2013, at 9:51 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 11/28/13 11:41 AM, Filip Pizlo wrote:
Here's why var is good enough provided that you do the var debug = false
thing at the top of the function:
I would think it would be done at window scope, or in some module
On Nov 28, 2013, at 10:40 AM, Brendan Eich wrote:
Kevin Smith wrote:
function*(a = yield/b/g) {
a = yield/b/g;
}
Why allow yield as an identifier in parameter defaults of generators?
Wouldn't it be simpler just to disallow there as well?
When proposing an
On Nov 28, 2013, at 11:24 AM, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
The reason it isn't allowed is that the generator object is not yet
instantiated and active at the point where a default value initializer would
be evaluated.
But just to be clear, defaults are evaluated per
On Nov 28, 2013, at 11:47 AM, Brendan Eich wrote:
On Nov 28, 2013, at 11:24 AM, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
The reason it isn't allowed is that the generator object is not yet
instantiated and active at the point where a default value initializer would
be evaluated.
'yield' is already disallowed in generator function default initializer
expressions (although I was reviewing the latest spec. revision yesterday
and there may still be still bugs I have to fix in that regard).
The reason it isn't allowed is that the generator object is not yet
instantiated
17 matches
Mail list logo
