The name works because they're sugar for a generator function immeidately
invoked:
I mean, that's true, but *why* is that true? What is the value of allowing you
to send in values via `.next(v)`, or send in exceptions via `.throw(e)`? Why
not just make them sugar for creating custom
From: Brendan Eich [bren...@mozilla.com]
The spec does not use desugaring, of course. While it could be done, in a
debugger the results would differ observably from a generator function with
let bindings. I think the spec should talk about this level of observability.
Hmm, getting somewhere
Le 06/09/2013 18:06, Brendan Eich a écrit :
Domenic Denicola mailto:dome...@domenicdenicola.com
September 6, 2013 8:48 AM
What is the value of allowing you to send in values via `.next(v)`,
or send in exceptions via `.throw(e)`?
An iterator does not reject .next calls that pass a value.
fair
mailto:dome...@domenicdenicola.com
September 6, 2013 7:44 AM
Why can't they just return iterable-iterators?
Consider:
```js
const g = (for (x of [1, 2, 3]) x * x);
g.next(); // returns { done: false, value: 1 }
g.next(5); // ???
g.throw(new Error(boo!)); // ???
```
As far as I can tell from
Le 06/09/2013 17:39, Brendan Eich a écrit :
Brandon Benvie wrote:
I don't think you're missing anything. They seem to be more
accurately described as Iterator Expressions than Generator
Expressions. It might be interesting if you could use yield inside
them, which would then make sending a
Domenic Denicola mailto:dome...@domenicdenicola.com
September 6, 2013 9:06 AM
From: Brendan Eich [bren...@mozilla.com]
Hmm, getting somewhere here. Could you expand on this? E.g. give a
code example where the observable results would be different if it
returned a iteratable-iterator instead
David Bruant mailto:bruan...@gmail.com
September 6, 2013 8:59 AM
Le 06/09/2013 17:39, Brendan Eich a écrit :
Brandon Benvie wrote:
I don't think you're missing anything. They seem to be more
accurately described as Iterator Expressions than Generator
Expressions. It might be interesting if you
From: Brendan Eich [bren...@mozilla.com]
In a debugger, I would see extra frames (without the debugger working to
merge them to preserve the appearance of a generator with let blocks). Think
about nested for-of heads, lifetimes of bindings. You need nested closures in
general.
Really? The
Domenic Denicola mailto:dome...@domenicdenicola.com
September 6, 2013 7:44 AM
Why can't they just return iterable-iterators?
...
What does having these be generators buy us? I am almost sure I'm
missing something.
The semantics is specified in terms of a generator function
(non-escaping
On Sep 6, 2013, at 9:04 AM, Brendan Eich wrote:
I keep forgetting how the ES6 draft uses generator comprehension, not
generator expression (the latter is a generator function expression).
Contrast with Python.
Perhaps iterator comprehension would be better terminlogy.
Allen
Allen Wirfs-Brock mailto:al...@wirfs-brock.com
September 6, 2013 10:02 AM
And we need to handle 'this' binding appropriately.
(for (x of [1,2, 3]) this[x])
can not desugar into
(function*() { for (let x of [1,2, 3]) yield this[x]; })()
because the 'this' binding would be wrong.
Good
Domenic Denicola mailto:dome...@domenicdenicola.com
September 6, 2013 9:13 AM
From: Brendan Eich [bren...@mozilla.com]
Really? The Firefox and Chrome debuggers, from what I can see, always
hide implementation stack frames from us.
This is not about implementation stack frames. The frame or
On 6 September 2013 18:04, Brendan Eich bren...@mozilla.com wrote:
The spec does not use desugaring, of course. While it could be done, in a
debugger the results would differ observably from a generator function with
let bindings. I think the spec should talk about this level of observability.
Brendan Eich wrote:
(function*() { for (let x of [1,2, 3]) yield this[x]; }).call(this)
Then of course one has to say the original value of .call, which is a
pain.
Desugaring is less convenient than it ought to be without uniform
parameterization support. (Generator arrow functions would
take my tire
Sent through Glass
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On Sep 6, 2013, at 9:06 AM, Brendan Eich wrote:
Domenic Denicola mailto:dome...@domenicdenicola.com
...
Why not just make them sugar for creating custom iterable-iterators without
shallow coroutine capabilities?
Because we need the shallow continuation to hold the implicitly declared
Andreas Rossberg mailto:rossb...@google.com
September 6, 2013 9:50 AM
But it doesn't. No matter which way you spec it, AFAICT, the
difference is not observable from within the (spec'ed) language. We
don't spec a debugger. Moreover, such details will already be
dependent on implementation and
Allen Wirfs-Brock mailto:al...@wirfs-brock.com
September 6, 2013 11:01 AM
Almost as good, a arrow function with a generator comprehension as its
expression body. For example, a factory for a generator with a lexical
this binding:
c = (for (p of c) if (p in this) this[p])
not much different
expressions return generators?
I was originally going to make a comment about this on your blog post, but this
now seems like a better place:
In http://domenic.me/2013/09/06/es6-iterators-generators-and-iterables/ you
state the following difinitions:
A generator is a specific type of iterator
I was originally going to make a comment about this on your blog post, but this
now seems like a better place:
In http://domenic.me/2013/09/06/es6-iterators-generators-and-iterables/ you
state the following difinitions:
A generator is a specific type of iterator which also has a throw method,
On Sep 6, 2013, at 10:22 AM, Brendan Eich wrote:
...
Good point, although the example in question did not use |this|, and I would
have adapted if it had:
(function*() { for (let x of [1,2, 3]) yield this[x]; }).call(this)
Too bad that we don't have generator arrow function syntax
Allen Wirfs-Brock mailto:al...@wirfs-brock.com
September 6, 2013 11:48 AM
On Sep 6, 2013, at 11:18 AM, Brendan Eich wrote:
Allen Wirfs-Brockmailto:al...@wirfs-brock.com
September 6, 2013 11:01 AM
Almost as good, a arrow function with a generator comprehension as its
expression body. For
On Sep 6, 2013, at 11:56 AM, Brendan Eich wrote:
Allen Wirfs-Brock mailto:al...@wirfs-brock.com
September 6, 2013 11:48 AM
On Sep 6, 2013, at 11:18 AM, Brendan Eich wrote:
Allen Wirfs-Brockmailto:al...@wirfs-brock.com
September 6, 2013 11:01 AM
Almost as good, a arrow function with a
On Sep 6, 2013, at 11:18 AM, Brendan Eich wrote:
Allen Wirfs-Brock mailto:al...@wirfs-brock.com
September 6, 2013 11:01 AM
Almost as good, a arrow function with a generator comprehension as its
expression body. For example, a factory for a generator with a lexical this
binding:
c =
On Fri, Sep 6, 2013 at 10:48 AM, Domenic Denicola
dome...@domenicdenicola.com wrote:
The name works because they're sugar for a generator function immeidately
invoked:
I mean, that's true, but *why* is that true?
It's the simplest way to achieve the desired behavior.
What is the value of
one language feature is
explained in terms of others. So for example (for (x of y) x+1) desugars into
something like {_it: y[@@iterator](), next() { var st = this._it.next(); if
(!st.done) return {value: st.value + 1, done: false}; return st; }}
On second thought, maybe equivalences are not so
The fact that s.match(/re/g) returns the array of all matches (with captures)
sucks some of the oxygen away from any /re/g.execAll(s) proposal.
But String.prototype.match has perlish hair (e.g., those capture groups
showing up in the result array).
Really? AFAICT, only the complete
[...] I think this makes a good case for a lazy execAll -- with a much better
name.
Candidates: r.iterate(s), r.iterateOver(s), r.execIterator(s) (blech!).
Suggest some!
I think “exec” should be in the name, to indicate that the new method is a
version of `exec()`.
Ideas:
–
return, e.g.,[ab, b] for the first iteration
given r and s as follows:
js r = /.(.)/g
/.(.)/g
js s = 'abcdefgh'
abcdefgh
js a = s.match(r)
[ab, cd, ef, gh]
js b = r.exec(s)
[ab, b]
Is this what the programmer wants? If not, String.prototype.match stands
ready, and again takes away motivation
Axel Rauschmayer wrote:
– execIter()
Not bad, I think better than execAll, which does not connote return of
an iterator, but which does perversely suggest returning an array of all
exec results.
`execAll()` may not be that bad. It’s not pretty, but it’s fairly easy
to guess what it does
will. A naive iterator that
calls exec would return, e.g.,[ab, b] for the first iteration given r and
s as follows:
js r = /.(.)/g
/.(.)/g
js s = 'abcdefgh'
abcdefgh
js a = s.match(r)
[ab, cd, ef, gh]
js b = r.exec(s)
[ab, b]
Is this what the programmer wants
Axel Rauschmayer wrote:
* /g flag must be set
* lastIndex must be 0
* can’t inline the regex, because it is needed as a pseudo-iterator
(more of an anti-pattern, anyway, but still)
* side effects via lastIndex may be a problem
Anything we do of the execAll/execIter kind had better be immune
On Thu, Aug 29, 2013 at 4:13 AM, Brendan Eich bren...@mozilla.com wrote:
Axel Rauschmayer wrote:
* /g flag must be set
* lastIndex must be 0
* can’t inline the regex, because it is needed as a pseudo-iterator (more
of an anti-pattern, anyway, but still)
* side effects via lastIndex may be
On Aug 29, 2013, at 1:13 AM, Brendan Eich bren...@mozilla.com wrote:
Axel Rauschmayer wrote:
* /g flag must be set
* lastIndex must be 0
* can’t inline the regex, because it is needed as a pseudo-iterator (more of
an anti-pattern, anyway, but still)
* side effects via lastIndex may be a
)
);
return a;
};
// example
'abcdefgh'.matchAll(/.(.)/g);
[
[ab, b],
[cd, d],
[ef, f],
[gh, h]
]
```
On Thu, Aug 29, 2013 at 9:24 AM, Oliver Hunt oli...@apple.com wrote:
On Aug 29, 2013, at 1:13 AM, Brendan Eich bren...@mozilla.com wrote:
Axel Rauschmayer wrote:
* /g flag must be set
Dean Landolt wrote:
I'd hate to see it throw. Ignoring lastIndex seems friendlier,
especially if it were called `execAll`. It probably shouldn't be
called `execIter` considering `exec` is already an iterator (even if a
bit crazy).
'exec' is not an iterator in any well-defined ES6 sense.
Oliver Hunt wrote:
I would favor ignoring lastIndex rather than throwing, but to be sure can you
clarify what you mean by global regexp?
One created with the 'g' flag, either literally (/re/g) or via the
constructor (new RegExp(src, 'g')).
If we're talking /.../g, then my feeling is that
to do recently).
I think to move on, it would be useful to consider whether the method should
return an array (which would be iterable and also have methods like `.map`
built in) or a custom, lazy iterable (which might be better for efficiency if
that laziness were useful, but will have
why @andrea
doesn't see this need (maybe it's not something he's found need to do
recently).
I think to move on, it would be useful to consider whether the method should
return an array (which would be iterable and also have methods like `.map`
built in) or a custom, lazy iterable (which
So you're in favor of returning the Iterable and then having people use
`Array.from` if they need an array?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
I'm guessing that code like:
```js
var matches = /foo/.execMultipleLazy('str')
for (let match of matches) {
//do something
}
for (let match of matches) {
//do something
}
for (let match of matches) {
//do something
}
```
Would go wrong somehow
Yes. This is a standard Python
On Wed, Aug 28, 2013 at 2:12 AM, Forbes Lindesay for...@lindesay.co.ukwrote:
a simple way to loop over the list of matches for a regular expression
it's about 10 years or more we have that .. so to make my very personal
statement clear:
I've got 99 problems in JS, make everything an iterator
Right, I don't care whether it's lazy. I only care that it exists. Nobody's
crying out for a lazy version of string split (at least not yet anyway). I
have had the issue of needing to loop over all the matches that a regular
expression has. It is a common, recurring issue that many
Forbes Lindesay wrote:
Let’s move on from whether it should exist (clearly it should)
Does String.prototype.match not count?
and stick to whether it should be an array, or lazy. Does anyone have
a strong opinion either way? The fact that all our regular expression
iteration thus far has
/2013 4:55 PM
To: Andrea Giammarchimailto:andrea.giammar...@gmail.com
Cc: Brendan Eichmailto:bren...@mozilla.com; es-discuss
listmailto:es-discuss@mozilla.org; Erik
Arvidssonmailto:erik.arvids...@gmail.com
Subject: RE: Letting RegExp method return something iterable?
Right, I don’t care whether
Ron Buckton wrote:
The advantage of a lazy execAll, is the ability to break out of the
for..of loop without the need to continue to traverse the input string
looking for matches. This is the same advantage that the `while(m =
re.exec())` has going for it. You can always be greedy by using
Le 27 août 2013 à 01:23, Brendan Eich bren...@mozilla.com a écrit :
Andrea Giammarchi wrote:
Is it very useful because you wrote for instead of while ?
```javascript
while (m = re.exec(str))
console.log(m[0])
;
```
It is, for two reasons:
1. in JS only for can have a let or var
sure you know everything as soon as you read `of` ... right ? How
objectives are your points ? If you know JS that while looks very simple,
IMO
On Tue, Aug 27, 2013 at 5:24 AM, Claude Pache claude.pa...@gmail.comwrote:
Le 27 août 2013 à 01:23, Brendan Eich bren...@mozilla.com a écrit :
let me rephrase ... I've no idea what this code does if not a syntax error
(and for different reasons)
`for (let m of re.execAll(str) {`
what is `of` ... will `let` mark that variable as local ? what is returned
and what will be `m` ?
I need to know these things ... this has nothing to do with
On Aug 27, 2013, at 9:42 AM, Andrea Giammarchi andrea.giammar...@gmail.com
wrote:
sure you know everything as soon as you read `of` ... right ?
Wrong. The nested assignment is idiomatic in C but not good for everyone (see
gcc's warning when not parenthesized in such contexts) due to == and =
losing argument ... as if assignment within condition has been a real
problem except for JSLint ... uhm, I don't think so but I am off this
conversation. Already said my point, feel free to (as usual) disagree ^_^
On Tue, Aug 27, 2013 at 9:48 AM, Brendan Eich bren...@mozilla.com wrote:
On Aug
Le 27 août 2013 à 18:48, Andrea Giammarchi andrea.giammar...@gmail.com a
écrit :
let me rephrase ... I've no idea what this code does if not a syntax error
(and for different reasons)
`for (let m of re.execAll(str) {`
what is `of` ... will `let` mark that variable as local ? what is
, $1) {
this.push($1);
}
function createMatches(str) {
var matches = [];
str.replace(re, addMatch.bind(matches));
return matches;
}
```
Above trick also scales more if you need to push more than a match in the
RegExp.
Although we might need a way to do similar thing without abusing other
On Mon, Aug 26, 2013 at 1:05 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
Long story short, I don't see any real use/case or any concrete advantage
with those examples so please make it more clear what's the problem you are
trying to solve and how these methods will concretely make
Is it very useful because you wrote for instead of while ?
```javascript
while (m = re.exec(str))
console.log(m[0])
;
```
I don't really see any concrete advantage, sorry, but maybe it's me not
liking at all this `iterable all the things` new trend.
On Mon, Aug 26, 2013 at 11:33 AM, Erik
Andrea Giammarchi wrote:
Is it very useful because you wrote for instead of while ?
```javascript
while (m = re.exec(str))
console.log(m[0])
;
```
It is, for two reasons:
1. in JS only for can have a let or var binding in the head.
2. the utility extends to all for-of variations: array
`String#split` already is iterable because it returns an array. What it isn't
is **lazy**.
To be equivalent to the for code, the let needs to go inside the body of the
while, not outside. This neatly demonstrates the key point:
- as it stands, writing this kind of code tends to be bug prone
to be really honest, most people will get it wrong regardless since thanks
to JSLint and friends they are use to declare everything on top and they
probably forgot for accepts `var` declarations.
I've never ever needed this syntax and I don't see the miracle. I am sure
somebody one day will use
At the moment, the following two methods abuse regular expressions as iterators
(if the /g flag is set):
* `RegExp.prototype.test()`
* `RegExp.prototype.exec()`
Would it make sense to create similar methods that return something iterable,
so that for-of can iterate over the result?
Axel
):
* `RegExp.prototype.test()`
* `RegExp.prototype.exec()`
Would it make sense to create similar methods that return something iterable,
so that for-of can iterate over the result?
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
that return something
iterable, so that for-of can iterate over the result?
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
___
es-discuss mailing list
es-discuss@mozilla.org
https
, August 24, 2013 16:45
To: es-discuss list
Subject: Re: Letting RegExp method return something iterable?
An example to make things clearer (thanks for the suggestion, Domenic):
https://gist.github.com/rauschma/6330265
On Aug 24, 2013, at 21:43 , Axel Rauschmayer
a...@rauschma.demailto:a
Hi,
Should the use strict directive work inside an arrow function?
Currently, for () = {'use strict'; return typeof this } returns
'object' in Firefox (it's the global object). Is it the intended behavior?
David
___
es-discuss mailing list
es
Le 06/06/2013 12:49, David Bruant a écrit :
Hi,
Should the use strict directive work inside an arrow function?
Currently, for () = {'use strict'; return typeof this } returns
'object' in Firefox (it's the global object). Is it the intended behavior?
Yeah... Don't bother answering. lexical
strict directive work inside an arrow function?
Currently, for () = {'use strict'; return typeof this } returns 'object'
in Firefox (it's the global object). Is it the intended behavior?
Yeah... Don't bother answering. lexical this. Appologies for the noise.
David
?
Currently, for () = {'use strict'; return typeof this } returns
'object' in Firefox (it's the global object). Is it the intended behavior?
Yeah... Don't bother answering. lexical this. Appologies for the noise.
David
__**_
es-discuss mailing list
es
feel fere to update/change/improve my quick note in that page, thanks.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/arrow_functions
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
#Destructuring_assignment_%28Merge_into_own_page.2Fsection%29
Right -- here are inline examples:
function pair(x, y) { return [x, h]; }
let [x, y] = pair(3,4);
This can be done without allocation with an optimization from Scheme
implementations, where the JIT looks into the continuation
I'd like to propose the incorporation of multiple return values into the ES
standard.
function foo(){
return 1,2,3;
}
let (a,b,c) = foo();
let (a,b) = foo(); // ignore c
let (a,...b) = foo() // a = 1, b = [2,3]
/* also useful for asynchronous functions returning a promise */
let (response
to propose the incorporation of multiple return values into the
ES standard.
function foo(){
return 1,2,3;
}
let (a,b,c) = foo();
let (a,b) = foo(); // ignore c
let (a,...b) = foo() // a = 1, b = [2,3]
/* also useful for asynchronous functions returning a promise */
let (response,headers
Anton Kovalyov wrote:
anders elo wrote:
I'd like to propose the incorporation of multiple return values into
the ES standard.
function foo(){
return 1,2,3;
}
let (a,b,c) = foo();
let (a,b) = foo(); // ignore c
let (a,...b) = foo() // a = 1, b = [2,3]
/* also useful
Brendan Eich wrote:
function pair(x, y) { return [x, h]; }
s/h/y/ there of course!
let [x, y] = pair(3,4);
And Nathan beat me to it -- sorry for not updating mail before replying...
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https
return a Boolean success
value
Why? no caller of [[PreventExtension]] currently uses such a result. In
general, we did try to make more of the internal methods return true/false
success indicators rather than deeply burying the decision of whether or not
an exception should be generated
2013/1/2 Allen Wirfs-Brock al...@wirfs-brock.com
Symbols don't need to fail on [[PreventExtensions]]. It always succeeds
for them since they are born non-extensible.
Sounds reasonable.
The major user facing change here is the possibility that
Object.preventExtensions will through if the
2012/12/31 Allen Wirfs-Brock al...@wirfs-brock.com
responses for chapter 8, except for 8.5 which will get its own message.
On Dec 29, 2012, at 2:37 PM, Tom Van Cutsem wrote:
Table 8:
* [[PreventExtensions]] internal method: should return a Boolean
success value
Why? no caller
I ave to recant on this after having doing some research (and actually
making it work). The original reason about ThisMode may still be true but
I'm less sure. It was basically about being unable to identify the correct
global `this` in strict mode since its not automatically provided for you,
and
) {
// what global am I?
}
}
method(){
if (this == null) {
// what global am I?
return value;
}
}
}
}
module Y {
// implicit use strict
var value = 30;
var global = this;
var x
Le 27/12/2012 02:52, Brandon Benvie a écrit :
As an aside, ES itself can't self-host its own builtins in strict mode
because of the (two of the very few) semantic differences that exist
between strict mode and non-strict mode: non-strict thrower properties
(which I've come to consider an
now
return to plan A. Any ES6 features that don't fit into non-strict mode
without contortion, including let and nested function, should be
available only in strict mode. For new function syntax, if
shoe-horning it into non-strict mode requires micro-modes as
previously discussed, then we shouldn't
incompatible changes. This experiment has failed, so we should now
return to plan A. Any ES6 features that don't fit into non-strict mode
without contortion, including let and nested function, should be
available only in strict mode. For new function syntax, if
shoe-horning it into non-strict mode
include web-breaking
incompatible changes. This experiment has failed, so we should now
return to plan A. Any ES6 features that don't fit into non-strict mode
without contortion, including let and nested function, should be
available only in strict mode. For new function syntax, if
shoe-horning
mode cannot include web-breaking
incompatible changes. This experiment has failed, so we should now
return to plan A. Any ES6 features that don't fit into non-strict mode
without contortion, including let and nested function, should be
available only in strict mode. For new function syntax
trying to
retrofit sense into ES6 non-strict mode, we knew that this was
speculative, because non-strict mode cannot include web-breaking
incompatible changes. This experiment has failed, so we should now
return to plan A. Any ES6 features that don't fit into non-strict mode
without
Mark, you cite some issues we need to work through, but opt-in via
pragma syntax beyond use strict is not one of them.
What's more, the big-picture claim in your Subject line (has failed
especially) is not true. In an overriding sense, 1JS can't fail, because
versioning is an anti-pattern (or
Mark S. Miller wrote:
On Wed, Dec 26, 2012 at 2:58 PM, Brendan Eichbren...@mozilla.com wrote:
Mark, you cite some issues we need to work through, but opt-in via pragma
syntax beyond use strict is not one of them.
Sorry for the confusion. As I just clarified in my response to Dave, I
am not
As an aside, ES itself can't self-host its own builtins in strict mode
because of the (two of the very few) semantic differences that exist
between strict mode and non-strict mode: non-strict thrower properties
(which I've come to consider an annoying blight that punishes developers in
order to
Er I meant ThrowTypeError.
On Wed, Dec 26, 2012 at 8:52 PM, Brandon Benvie
bran...@brandonbenvie.comwrote:
As an aside, ES itself can't self-host its own builtins in strict mode
because of the (two of the very few) semantic differences that exist
between strict mode and non-strict mode:
As an aside, ES itself can't self-host its own builtins in strict mode
because of the (two of the very few) semantic differences that exist between
strict mode and non-strict mode: non-strict thrower properties (which I've
come to consider an annoying blight that punishes developers in
It's a bit unclear to me how arrow functions react to semicolons, for
example:
var a = (c) = {
var b = 2;
b * c;
}
a(4);
To me, it seems like this should return undefined. After all, the last
statement in the function is empty. To actually return b * c, you should
drop the semicolon:
var
Le 29/11/2012 09:41, Jussi Kalliokoski a écrit :
It's a bit unclear to me how arrow functions react to semicolons, for
example:
var a = (c) = {
var b = 2;
b * c;
}
a(4);
To me, it seems like this should return undefined. After all, the last
statement in the function is empty
Jussi Kalliokoski wrote:
It's a bit unclear to me how arrow functions react to semicolons, for
example:
var a = (c) = {
var b = 2;
b * c;
}
a(4);
To me, it seems like this should return undefined. After all, the last
statement in the function is empty.
Not by the grammar.
You would
this is the case in es5, not counting preventing
syntactical errors. But with implicit return values, the empty
statement could make the difference.
Not sure if this is a problem, just noting that it seems to be a
change, one that'll be hard to debug for once implicit returns are
heavily used. OTOH
It's a bit unclear to me how arrow functions react to semicolons, for
example:
var a = (c) = {
var b = 2;
b * c;
}
a(4);
Hmmm... I was under the impression that arrow functions with normal
function bodies do *not* implicitly return anything. Maybe I need to
adjust my spec goggles
Kevin Smith wrote:
It's a bit unclear to me how arrow functions react to semicolons,
for example:
var a = (c) = {
var b = 2;
b * c;
}
a(4);
Hmmm... I was under the impression that arrow functions with normal
function bodies do *not* implicitly return
*not* implicitly return anything. Maybe I need to
adjust my spec goggles, but I don't see that in the latest draft.
This is correct.
var a = (c) = {
var b = 2;
b * c;
}
a(4); // undefined
Rick
Kevin
___
es-discuss mailing list
es
that arrow functions with normal
function bodies do *not* implicitly return anything. Maybe I need to
adjust my spec goggles, but I don't see that in the latest draft.
Oh (and d'oh!) you are quite right. There's no implicit return or other
TCP aspect save lexical-|this|, at all.
Sorry
b = 2;
b * c;
}
a(4);
Hmmm... I was under the impression that arrow functions with normal
function bodies do *not* implicitly return anything. Maybe I need to
adjust my spec goggles, but I don't see that in the latest draft.
Oh (and d'oh!) you are quite right. There's
Hello Hackers,
If there was a easy way to wrap an asynchronous in a synchronous API would
it not be easy? Because we can wrap it that way any API will need to accept
a callback to return proceed values.
I bit be speaking absolute non sense here, but just felt something like
that might makes
? Because we can wrap it that way any API will
need to accept a callback to return proceed values.
I bit be speaking absolute non sense here, but just felt something
like that might makes things easier, while I was coding THIS
https://github.com/hemanth/node-rsj/commit
Hackers,
If there was a easy way to wrap an asynchronous in a synchronous API
would it not be easy? Because we can wrap it that way any API will need to
accept a callback to return proceed values.
I bit be speaking absolute non sense here, but just felt something like
that might makes things
201 - 300 of 453 matches
Mail list logo
