Re: Does async/await solve a real problem?

functions. It has a nice example of such an unexpected race condition. Kind regards, Bergi ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: short-circuiting Array.prototype.reduce

https://en.wikipedia.org/wiki/Absorbing_element would benefit from this. Bergi ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Forwarding `return()` in generators

[[Iterated*]] internal property to `undefined`? Bergi ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Always close iterators?

Axel Rauschmayer wrote: Given that redundant calls to `return()` don’t make a difference (h/t Bergi) I'm sorry, that was not 100% accurate. I only referred to `.return(x)` returning {done:true, value:x} and `.throw(e)` being equivalent to `throw e;` when the generator was never started

Re: Always close iterators?

is it forgotten? Bergi ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Expression Closures as Compliment to Arrow Functions

think arrow functions have same problem. How is var y = (a) = a ? f : x++ (1); evaluated (or is it syntactically valid at all)? Bergi ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Forwarding `return()` in generators

; } else throw e; } finally { if (!done) iterator.return(); } Bergi ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Forwarding `return()` in generators

`.return()` on the iterator when `n` values have been taken out of it. Bergi ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Object arithmetic--operator alternative to Object.assign

for Object.assign. It uses an := operator, so your example would read obj1 := {x, y}; Bergi ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Accepting an array as the first parameter to String.prototype.includes

this (to allow for native optimisations with fancy string search algorithms), I'd suggest to use a different method name like `String.prototype.includesAll`. Bergi ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es

Re: Idiomatic representation of { buffer, bytesRead }

Kevin Smith schrieb: Should have been: source.next(dataView) - PromiseIteratorResultDataView which you kind of need anyway ; ) Wouldn't `.next()` rather need to return an IteratorResultPromiseDataView? Bergi ___ es-discuss mailing list es

Re: Idiomatic representation of { buffer, bytesRead }

, right, I should've read your first post properly - you were talking about future *asynchronous* generators. Bergi ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: The result of Generator.prototype.return

your result promise is cancelled. Bergi ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

super() call in methods

class's method, but does nothing - not even throwing an error! Should an exception been thrown if the `func` returned by `GetSuperConstructor()` is `%FunctionPrototype%`? Best regards, Bergi PS: there's a typo in `GetSuperConstructor`: s/activeFuntion/activeFunction

Re: super() call in methods

Allen Wirfs-Brock schrieb: On Dec 16, 2014, at 1:18 PM, Bergi wrote: ... I've read https://esdiscuss.org/topic/referencing-super and it seems that needing to call `super.describe()`/`super.render()`/`super.say()` is intended behaviour. I'm fine with that, as explicit is better than implicit

Re: Array.from API

wanted to completely omit passed values you'd rather overwrite the `.from` method as a whole instead of relying on the inherited one. Bergi ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

<    1   2