Re: Promise sub-class: super((resolve, reject) = this) ?

To clarify things, since I don't think it's been made abundantly clear, the example that Sebastian gave would work in a standard ES6 environment, correct? It is only if the callback were executed synchronously that the exception would be thrown since the `this` binding has not yet been

Re: String.substitute

Template literals evaluate to simple strings, there is no way to pass a reference to an un-evaluated template literal. The function method is the only way. Programmatically ``` String.substitute({ year: 2015}, `Last year was ${year-1}`); ``` is identical to ``` var str = `Last year was

Re: String.substitute

Could be possible to pass a string with instead of \`\` At that point, you are implementing a templating language that happens to match up syntactically with template literals. You'd also then be moving parsing of the template to runtime instead of compile time, which will slow things down.

Re: Incompatibility between generators and arrays in the Iterator protocol

The value set when `done: true` is set is not considered part of the iterated list, which is why you are seeing what you are seeing. The expected behavior is defined as `done: false` for all yielded values, and `done: true` when iteration has completed. That same behavior also applies for

Re: Cancelable promises proposal

want to show disinterest that the query is irrelevant now: ```js let done = query.done; done.then(updateView).then(log, logAbort); done.ignore(updateView); ``` Does this answer you question? On Aug 5, 2015, at 10:51 AM, Logan Smyth loganfsm...@gmail.com wrote: Glen, sorry if this has been

Re: Cancelable promises proposal

Glen, sorry if this has been covered in other discussions, but it's not clear to me so I wanted to ask. Are there some example use-cases where being able to `.ignore` is preferable to having the promise reject? Promise chains are about defining flows of data and I can't really see a case where

Re: for statement with index and value

Unfortunately we can't have both ``` for (let value of values){ ``` and ``` for (let [index, value] of values){ ``` Over all, the first one is the more likely one on a day-to-day basis. The `[]` are needed because the `for...of` follows the standard rules for assignment, so it uses standard

Re: Exporting Symbols

The main issue is that modules are statically analysable and imports/exports are processed before the module executes, and the behavior of a symbol is by definition a runtime thing. Until the code executes, there would be no symbol object, and there would be no way to know what thing was being

Re: `super` and superclass constructor return values

Yup, correct. The value of the `this` binding is initialized to the result of `[[Construct]]`, which will either be the parent constructor `this` binding, or the explicitly returned value. Relevant spec links: Evaluating `super()`: (12.3.5.1)

Re: Modifying ES6 module exports

The `{}` shouldn't be from Babel, it has handled all circular dependency cases as far as I'm aware. I'm curious to know what the end cause of this issue is, but this isn't really the right discussion forum for it. Joe, if you do end up making a simplified example that can be tested, I'd be happy

Re: Modifying ES6 module exports

To start, an object is definitely not what I'd expect. The core thing to remember with ES6 modules is that while imports are live bindings, you still need to write your code in such a way that it has no run-time circular dependencies. In your specific examples, you are importing `A` first, which

Re: exports at the top of the file

> > ```js > export default myConst; > const myConst = {}; > ``` > would throw because when the export is evaluated Correct, if you wanted to export `myConst` as the default without that issue, you'd want to do ``` export {myConst as default}; const myConst = {}; ``` to declaratively expose the

Re: Subclassing native class and instanceof operator

The correct spec behavior is to return an instance of `MyError`. Step 7 in your example is not equivalent to calling `Error` without `new`, which seems to be your assumption. The `newTarget` parameter passed to `Construct` is used to determine the prototype of the final object, and in this context

Re: Import wildcards

I think my biggest issue with this is that it seems like a solution in search of a problem. I can kind of see that you might end up with a setup where common property prefixes are common in the case of config files where you want many config options in one file. However, in the vast majority of JS

Re: Ignoring arguments

``` function fn(...[a, b, c, ...rest]){} ``` is mostly no different than ``` function fn(...args){ let [a, b, c, ...rest] = args; } ``` This wasn't officially allowed in ES2015, where only an Identifier was allowed as a rest param target in arguments, but the behavior has since been expanded

Re: `await null` to stay in the same tick?

Joe, if you have a specific example, feel free to file an issue and I can take a look. From what I can see,

Re: Negative indexes

Felipe, this has been discussed in the other thread that was just linked: https://esdiscuss.org/topic/javascript-language-feature-idea. `arr[-1]` is not a workable solution because it could break existing code. On Mon, Feb 1, 2016 at 4:43 PM, Felipe Nascimento de Moura < felipenmo...@gmail.com>

Re: Assignments to SuperProperty are confusing and may be useless

Assignment to a super properly definitely has its uses, in the same way that calling a super method does, though definitely less common. Consider an example where a subclass wants to override a parent class's accessor property: ``` class Parent { get prop(){ return this._prop; } set

Re: Class and Property Initialization

Bradley, looks like you have a typo and should be using the `this` argument you pass to `exec` rather than `this` in the arrow? ``` class B extends A { constructor() { super(inst => { inst.b = 2; }); } } ``` On Fri, Mar 18, 2016 at 8:27 AM, Bradley Meck

Re: Object.prototype.forIn

Edwin, the original example loop explicitly checks `obj.hasOwnProperty(key)`, so properties in the prototype chain are not an issue here. On Fri, Mar 4, 2016 at 1:04 PM, Edwin Reynoso wrote: > Sorry guys but this is very wrong, for in, loops through all properties > even the

Re: Has the bind operator been revoked from proposal?

The main page is only proposals >= Stage 1. All of the Stage 0 proposals are on a separate page: https://github.com/tc39/ecma262/blob/master/stage0.md On Sat, Mar 5, 2016 at 11:26 AM, JD Isaacks wrote: > Looking here: https://github.com/tc39/ecma262 > > I no longer see the

Re: Object.prototype.forIn

You can already achieve this in ES5 with ``` Object.keys(obj).forEach(key => { }); ``` or in ES6 with ``` var key; for (key of Object.keys(obj)){ } ``` And with the new proposal, you'll also have `Object.values` for values and `Object.entries` for key/value pairs:

Re: Is it possible to define an array iterator that adjusts to your for-of syntax?

It is not possible to detect this. ``` for (let [i, elem] of arr){ ``` is no different that than ``` for (let pair of arr){ let [i, elem] = pair; ``` You are destructuring the result of an iterator, and the initialization of the iterator is independent from the initialization of the

Re: Redefining a let variable inside a for loop scope doesn't work?

I think you may be misunderstanding that error. `for (let n of foo){ }` does create an `n` value inside the loop. The issue isn't that `n` doesn't exist inside the loop, it's that `n` has already been shadowed by the time `n.a` is evaluated, meaning you're accessing `.a` of an uninitialized

Re: How to solve this basic ES6-module circular dependency problem?

Keep in mind `let A = A;` is a TDZ error in any real ES6 environment. The example I posted works properly with Babel's live-binding implementation and should require less repetition. What were your thoughts on it? On Thu, Aug 11, 2016 at 12:23 AM, /#!/JoePea wrote: > Alright,

Re: How to solve this basic ES6-module circular dependency problem?

You could also swap that around to simplify the logic in the individual classes, e.g. ``` // --- Module A import C, {initC} from './c'; initC(); console.log('Module A', C) class A extends C { // ... } export {A as default} ``` then export that function to force-initialize the `C`

Re: The `super` keyword doesn't work as it should?

Joe, it seems like you've focused on `super === Object.getPrototypeOf(this)` as the overall ideal without considering the issues with it. I've tried to put together a few counterexamples below. Say you have a base set up like this: ``` var a = { prop: null, method(){ this.prop = 4;

Re: The `super` keyword doesn't work as it should?

Joe, yes sorry, my mistake. `a` should have `__proto__: b`, and `b` should have `__proto__: c` in my example, that's what I get for not validating it better. Each could `return` but since `a.method` was the only one I called, it was the only one I put the `return` in. On Wed, Jul 20, 2016 at 3:27

Re: Ambiguity with default exports and live bindings?

>From the code perspective, changing the value of `A` will not update the value of the export, but it's not quite that it's not live, it's that you're not exporting what you think you're exporting. ``` export default A; ``` is essentially short for ``` const fakeInaccessibleVariable = A; export

Re: How to solve this basic ES6-module circular dependency problem?

t A from './A' > import B from './B' > > console.log('module C') > let C > > export function initC(){ > if (C) return > > console.log('initC!!!') > > C = class C { > constructor() { > // this may run later, after all three modules are evaluated, > or &g

Re: Why can't we `let s = super`?

`super()` right now is a special syntactic feature, just like the new proposed `import()` and such. To have `super` behave like a variable and be consistent, `super.foo()` would also then be accessing a property on that variable, instead of calling a method from the parent constructor prototype.

Re: Would it be possible to add “await on first use” to the language?

So you'd be imagining something that would create a variable that would automatically await when accessed, like ``` async function makePizza(sauceType = 'red') { await const dough = makeDough(); await const sauce = makeSauce(sauceType); await const cheese =

Re: Written Proposal for "package" Keyword for ES20XX Imports

> What does the *spec* say should happen in that situation? It would be a TDZ error, rather than `undefined`, in a real implementation of block scoping + ES6 modules. The ordering still means that `A` won't exist when `class B extends A` runs. On Wed, Feb 22, 2017 at 10:00 AM, T.J. Crowder <

Re: Written Proposal for "package" Keyword for ES20XX Imports

dering still means that `A` won't >> exist when `class B extends A` runs. > > > @Logan So it sounds like this TDZ error would be at runtime as opposed to > compile-time, correct? Do you have a link to where this is referenced? Both > cases would imply the ES6 spec does not trul

Re: Written Proposal for "package" Keyword for ES20XX Imports

I don't have tons of comments on the proposal as a whole, but I do think there may be confusion about ES6 imports. Imports are resolved and processed and modules linked before any execution of the module body takes place. I can't tell from your description if you are reading that differently. On

Re: Written Proposal for "package" Keyword for ES20XX Imports

coming from another language might expect this to work > based on how ES6 imports are described. I think the behavior of the package > keyword could be much more transparent about what it's capable of. > > > > On Tue, Feb 21, 2017 at 1:56 PM, Logan Smyth <loganfsm...@gmail.com>

Re: Why are class getters/setters non-enumerable?

FYI, ``` const xDesc = Object.getOwnPropertyDescriptor(XYZValues.prototype, 'x') xDesc.enumerable = true Object.defineProperty(XYZValues.prototype, 'x', xDesc) const yDesc = Object.getOwnPropertyDescriptor(XYZValues.prototype, 'y') yDesc.enumerable = true

Re: How to solve this basic ES6-module circular dependency problem?

sting which I think should be generally avoided in order to make code > less error-prone and easier to understand. This behavior would have been > nearly-impossible to know about without the knowledge gained from this > conversation (or from reading the spec in depth which can be difficult).

Re: Array tail destructuring

FYI there's also some previous discussion on this here for those interested: https://mail.mozilla.org/pipermail/es-discuss/2015-October/044306.html https://esdiscuss.org/topic/rest-parameters On Mon, Oct 3, 2016 at 3:05 PM, Olivier Lalonde wrote: > > I think Olivier's point

Re: Accesssing ES6 class constructor function

> The enforcement seems pointless to me So we're all on the same page, this restriction exists because it means `class` syntax can extend builtin types like `Map`, `Set`, `Array` and `Error` and such, which cannot be extended (with correct functionality anyway) in standard ES5. By delaying

Re: [Idea] Bind operator as some sort of property acessor

Unless I'm misunderstanding what you are looking for, I believe the current proposal accounts for this as `::arr.push` with no expression before the `::`. Logan On Tue, Mar 7, 2017 at 4:33 PM, Augusto Moura wrote: > Before I open any suggestion for my ideia in the

Re: Array.prototype.tap

You could always hack it and use the third argument :D ``` var tap = f => (v, i, arr) => { if (i === arr.length - 1) f(arr); return v; }; ``` Fine for debugging at least, but not necessarily your overall goal. On Sun, Jul 16, 2017 at 11:20 AM, Eli White wrote: > That

Re: Pipe operator for JavaScript

There's been talk of this before here and in https://github.com/gilbert/es-pipeline-operator among other places. Most recently this was posted, which sounds like promising progress: https://github.com/gilbert/es-pipeline-operator/issues/33#issuecomment-306986211 On Tue, Jul 11, 2017 at 1:02 PM,

Re: Inline variable dereferencing of object field names

Assuming in your first example you meant query.$pull[team] = userId; not query[team] = userId; then your second example is already valid a ES6 computed property and does exactly what you appear to be looking for. On Sun, Jul 23, 2017 at 8:15 PM, Sebastian Malton

Re: Support underscores in numbers

There is currently an active proposal for this: https://github.com/tc39/proposal-numeric-separator On Wed, Jul 26, 2017 at 1:47 PM, Alexander Craggs < alexan...@debenclipper.com> wrote: > Large number are hard to read in JavaScript, is 2384923842 over a > billion? Or just several hundred

Re: Block scoped prototype extensions

This seems like a difficult thing to do because the prototype chain is only objects, so mutating them for the context of a single scope isn't easily done. A few cases come to mind as extremely confusing: * If you override the prototype in a scope then pass the object to another function inside

Re: import.meta and TC39 process as a whole

like >> ad-hoc shortsighted solutions with no respect for the language or its >> evolution. “We need a thing, we have nowhere to put this thing, let’s add >> this thing to a keyword, because new.target (bad design) has opened a door >> for us”. >> >> > I'd _much_

Re: import.meta and TC39 process as a whole

Meta, module). > - Set module.[[ImportMeta]] to importMeta. > - Let result be the result of evaluating module.[[ECMAScriptCode]]. > - Suspend moduleCxt and remove it from the execution context stack. > - Resume the context that is now on the top of the execution context stack > as the runn

Re: rest getters and setters (sorry, __noSuchMethod__ again)

> but i can not act like this inside the Object, because i am not working with the Proxy You're not quite taking into account the behavior of `this` in JS. `this` is set at call-time, so when you do ``` class items { // ... getItem3(){ return this.$3; } } ``` `this` depends

Re: @strict class decorator

Not necessarily 100% what you're going for, but you can get an error for this behavior if you use `Object.preventExtensions()` on the class, e.g. ``` class Person { name; constructor() { Object.preventExtensions(this); } } ``` Currently because of an edge-case in Babel 6's class

Re: rest getters and setters (sorry, __noSuchMethod__ again)

1/ > > I see, the getter is called on the object itself and not on the proxy > > > > > > > > > > > > 2017-07-29 2:05 GMT+02:00 Logan Smyth <loganfsm...@gmail.com>: > >> > but i can not act like this inside the Object, because i am not >>

Re: Re: Array.prototype.toObjectByProperty( element=>element.property )

> Object entries() is another strange case. Iterating over Object.keys with key=> leaves myObject[key] to access the value, whereas iterating over Object.entries with entry=> requires entry[0] and entry[1] which seems more verbose for access, and less readable! So do you know why this was

Re: Re: Defer expression

`Promise.try` calls its callback synchronously like `new Promise` does, so it would not be a substitute for this case. On Wed, Aug 16, 2017 at 1:29 PM, Darien Valentine wrote: > Deferring can mean different things, but generally `then` covers this well > (specifically,

Re: Re: Defer expression

`setTimeout` it is defined in the HTML spec, https://www.w3.org/TR/html5/single-page.html#timers, not the ECMA spec. The ECMA spec has no concept of time-based delays at all, promise-based or otherwise. On Wed, Aug 16, 2017 at 11:03 PM, Naveen Chawla wrote: > An in built

Expected function parameter scoping behavioor

Hey all, We're currently exploring some changes to Babel's behavior for function parameter default scoping, and I was hoping to validate my understanding of the spec, because my reading of the spec does not conform to Chrome or FF's behavior. Alternatively if you know bugs for those engines for

Re: Expected function parameter scoping behavioor

e body. > > Allen > > On May 9, 2017, at 12:40 PM, Logan Smyth <loganfsm...@gmail.com> wrote: > > Hey all, > We're currently exploring some changes to Babel's behavior for function > parameter default scoping, and I was hoping to validate my understanding of > the sp

Re: State of Decorators

Keep in mind that the available implementations don't necessarily reflect the state of the spec, and that they are maintained two independent groups. None of the current implementations reflect the current state of the spec, which has changed a lot over the last years. Babel for instance is also

Re: throwing/breaking inside a for-of loop does not call iterator.throw()

As far as I know, `.throw` exists as a way to inject behavior into an in-progress iterator. See in https://tc39.github.io/ecma262/#table-54 for "throw" > Invoking this method notifies the Iterator object that the caller has detected an error condition. But the key thing is that the spec never

Re: How it feels to learn JavaScript in 2016

`typeof null` is `"object"` for entirely historical implementation reasons, not because things that don't fit the existing primitive list are automatically `object`. Adding a new typeof `symbol` doesn't change a precedent, because there was no such precedent. I understand that it's not what you

Re: How it feels to learn JavaScript in 2016

Kai, that's not what backward-compatibility means though. It doesn't mean that new code automatically works with older code, it means existing code doesn't break when used alongside other existing code. Yes, adding new features to the language means that assumptions made by old code may not hold

Re: Can `new` be optional?

> I also don't see how decorators can solve it. Making to wrapper for class constructor to allow the constructor to callable would be fairly straightforward, e.g. ``` function callable(cls) { function Wrapper(...args) { return Reflect.construct(cls, args, new.target || cls); }

Re: Question of the Day: What about all this asynchrony?

A nit, but that would have to be `for (const move of moves) await doMoveAsync()` since the `forEach` callback is a normal function. On Tue, Nov 7, 2017 at 11:47 AM, Naveen Chawla wrote: > ... that should be `await doMoveAsync()` > > On Wed, 8 Nov 2017 at 01:16 Naveen

Re: Monkey patching constructors in builtin class hierarchies?

Given that these are constructors that you don't own, adding your own properties to them seems like an overall ugly approach to me. Why not store your data separately in a WeakMap and rather than injecting properties onto existing objects? Then you can initialize the stored data on first access of

Re: Number.MAX_SAFE_INTEGER incorrect?

To clarify, the "you can still add one to them" is probably the most important part in that definition, given your question. > Anyway, this definition departs from similar definitions in other languages and AFAICT, existing JavaScript implementations have no problems using 2^53 as an integer.

Re: Proposal: Add a global Infinitesimal property

It doesn't sound like `Number.MIN_VALUE` is what you want, is it? You're asking for something like `Number.EPSILON`, but relative to `0` instead of `1`? On Sat, May 12, 2018 at 9:57 AM, kdex wrote: > Already available, just prepend a minus sign like so: > > ```js >

Re: Proposal: Add a global Infinitesimal property

es smaller than `Number.MIN_VALUE`. > > On Saturday, May 12, 2018 7:01:38 PM CEST Logan Smyth wrote: > > It doesn't sound like `Number.MIN_VALUE` is what you want, is it? You're > > asking for something like `Number.EPSILON`, but relative to `0` instead > of > > `1`? >

Re: Overload str.replace to take a Map?

> It wouldn't necessarily break existing API, since String.prototype.replace currently accepts only RegExp or strings. Not quite accurate. It accepts anything with a `Symbol.replace` property, or a string. Given that, what you're describing can be implemented as ``` Map.prototype[Symbol.replace]

Re: Markdown Documents of ES8

The easiest version of the spec to read is probably the HTML version at https://www.ecma-international.org/ecma-262/8.0/. There isn't a markdown version to look at. The spec is maintained in https://github.com/tc39/ecma262/blob/master/spec.html as HTML markup with some custom elements. On Sun,

Re: Proposal: Alternative public, private, static syntax and questions

The `#foo` shorthand part of the proposal was removed: https://github.com/ tc39/proposal-class-fields/issues/21 On Thu, Jan 11, 2018 at 2:26 PM, Isiah Meadows wrote: > The proposal does a very poor job of explaining this, but `#foo` is a > shorthand for `this.#foo`, much

Re: About Reference type

> What data is of type Reference in the specification? If you search for "value of type Reference" in the spec, I think it finds all of the places where references are created. References come from references to variable names, or from things like property accesses like `foo.bar` or `foo['bar']`

Re: Class data member declarations proposal idea

ote: > On Fri, 10 Aug 2018 at 00:09, Logan Smyth wrote: > >> It might help if you could clarify how your proposal diverges from the >> class fields proposal that you linked to. From purely a syntactic view, >> ignoring the type annotations, I don't see an obvious difference, so

Re: Class data member declarations proposal idea

It might help if you could clarify how your proposal diverges from the class fields proposal that you linked to. From purely a syntactic view, ignoring the type annotations, I don't see an obvious difference, so it is hard to tell what your expectations are. You state "I have shown the idea of

Re: constructor, super, and data members issue

Generally if something is required during construction, it would be best to pass it down as part of the constructor options. For example, you could do ``` class Base { constructor({ idAttribute = "id"}) { this.idAttribute = idAttribute; } } class Derived extends Base { constructor() {

Re: constructor, super, and data members issue

t;>>> } >>>>> } >>>>> >>>>> class Foo extends Bar { >>>>> _initiedSuper = false; >>>>> _bar = 'in foo'; >>>>> >>>>> constructor() { >>>>> super(); >>>>

Re: Module Namespace Objects - "writable"

Here's one other post about this from Allen: https://github.com/tc39/ecma262/issues/749#issuecomment-265637923 On Wed, Oct 24, 2018 at 10:42 AM T.J. Crowder < tj.crow...@farsightsoftware.com> wrote: > I'm curious if I've inferred the rationale for something correctly. > > The module namespace

Expectations around line ending behavior for U+2028 and U+2029

Something I've recently realized just how much U+2028 and U+2029 being newlines introduces a mismatch between different parts of a dev environment, and I'm curious for thoughts. Engines understandable take these two characters into account when defining their line number offsets in stack traces,

Re: Expectations around line ending behavior for U+2028 and U+2029

these input > elements don't terminate lines. > > On Wed, Oct 24, 2018 at 3:58 PM Logan Smyth wrote: > >> Something I've recently realized just how much U+2028 and U+2029 being >> newlines introduces a mismatch between different parts of a dev >> environment, and I'm curious

Re: Expectations around line ending behavior for U+2028 and U+2029

Great, thank you for that resource Allen, it's helpful to have something concrete to consider. What you'd prefer is that that other languages should also be rendered with U+2028/29 as creating new lines, even though their specifications do not define them as lines? That means that any parser for

Re: Expectations around line ending behavior for U+2028 and U+2029

PM Waldemar Horwat wrote: > On 10/25/2018 09:24 AM, Logan Smyth wrote: > > Yeah, /LineTerminatorSequence/ is definitely the canonical definition of > line numbers in JS at the moment. As we explore > https://github.com/tc39/proposal-error-stacks, it would be good to > clearly spec

Re: Expectations around line ending behavior for U+2028 and U+2029

; On Fri, Oct 26, 2018 at 5:49 PM Logan Smyth wrote: > > > > Great, thank you for that resource Allen, it's helpful to have something > concrete to consider. > > > > What you'd prefer is that that other languages should also be rendered > with U+2028/29 as creating n

Re: await enhancement proposal: Wrap Array return values with Promise.all

Making `await` itself do this would be a breaking change, so that'd be very unlikely. There was discussion around an `await*` similar to the existing `yield*` for generators, but I think it was deemed unneeded complexity since `Promise.all` was already pretty easy to use, especially since it isn't

Re: NumberFormat maxSignificantDigits Limit

It does seem unclear why the limit is 21. Is that maybe the most you need to uniquely stringify any double value? > an only encode up to 17 significant decimal digits That's true for decimal values, but the limit of 21 would also include the fractional portion of the double value as well, so

Re: Callable objects protocol

The type of the target is what affects typeof, indirectly by setting the [[Call]] value. If an `apply` or `construct` trap handler is given and the target isn't a function, they are ignored. See step 7 in https://www.ecma-international.org/ecma-262/9.0/index.html#sec-proxycreate On Tue, Dec 4,

Re: New: proposal-class-modifiers

level, but not really at a >> dynamic runtime level. Also, this is lacking precedent in other >> dynamic languages with classes: Python, Ruby, Smalltalk, Lua, Io, and >> pretty much every other dynamic language with class- or >> prototype-based inheritance (that wasn't made for the J

Re: New: proposal-class-modifiers

Wouldn't it be better `abstract`'s `target.prototype === newTarget.prototype` check to be `target === newTarget`? It's not really the prototype that is at issue here, it is the class constructor itself. It would not be good if you could sidestep `abstract` by taking the prototype from the class

Re: Symbol.inspect

Symbols seems like a good way to do this, but since the ECMA spec doesn't define anything about IO, I don't think this would be their responsibility. This seems more like something the console API spec would expose, e.g. `console.inspect`, where the `Symbol.XX` namespace would be reserved for

Re: Promise.resolve

`Promise` can be subclassed, so the `this` context for `resolve` affects what class is instantiated. On Sat, Feb 2, 2019 at 12:25 PM Sultan wrote: > Was there any reason Promise.resolve was not afforded the ability to > dispatch outside of `this` pointing to the `Promise` constructor? > > For

Re: how many async-modules can js-app practically load?

Can you elaborate on what loading state you need to keep track of? What is the bottleneck that you run into? Also to be sure, when you say async-load, do you mean `import()`? On Wed, May 22, 2019, 20:17 kai zhu wrote: > i don't use es-modules. > but with amd/requirejs, I start having trouble

Re: Promises: unhandled rejections and finally()

> Could someone point me to something that would help me to understand the logic here? It looks like the first finally() is getting a “free pass” while only the 2nd and subsequent ones trigger their own unhandled-rejection warnings. I think the best place to start in understanding this would be

Re: [Proposal] Allow rest parameter on try... catch

I'm not sure this fits nicely into things. The issue is that `Promise.all` rejects as soon as it gets _any_ errors, so your `catch` block will run before there are multiple errors. The syntax used around `Promise.all` should not influence the behavior of `Promise.all` itself, so the only way to do

Re: Resuming execution contexts

> as this code does not seem to take an argument. The resumption state set by `GeneratorStart` does not take an argument because there is no way to access the first resumption value in a generator, though there is the `function.sent` proposal to allow that: