On Apr 29, 2015, at 8:44 AM, C. Scott Ananian wrote: > On Wed, Apr 29, 2015 at 1:06 AM, Brendan Eich <[email protected]> wrote: > Kevin Smith wrote: > So what would the ideal Promise.resolve semantics do? I'm not sure, maybe > use SpeciesConstructor instead of [[PromiseConstructor]]? > > This removes the wart in my view, has no less integrity. C. Scott? > > Making this concrete, here would be the new text for 25.4.4.5 > Promise.resolve(x): > The resolve function returns either a new promise resolved with the passed > argument, or the argument itself if the argument is a promise produced by > this constructor. > 1. Let C be the this value. > 2. If IsPromise(x) is true, > a. Let constructor be the value of SpeciesConstructor(x, %Promise%) > b. If SameValue(constructor, C) is true, return x. > 3. If Type(C) is not Object, throw a TypeError exception. > 4. Let S be Get(C, @@species). > 5. ReturnIfAbrupt(S). > 6. If S is neither undefined nor null, let C be S. > 7. Let promiseCapability be NewPromiseCapability(C) > [...remainer elided...] > > Step 2a is the only change. (It was previously "Let constructor be the value > of x's [[PromiseConstructor]] internal slot.")
But SpeciesConstructor (or any access to x's @@species) goes through `x.constructor` and my recollection is that the motivation for adding [[PromiseConstructor]] was that 'constructor' was not sufficiently tamper proof. From that perspective, it seems that SpeciesConstructor is actually worse than just accessing `x.constructor`. Also, in a private message Mark Miller mentioned that the primarily security invariant he's concerned about really relates to the behavior of the `then` method of the object returned by `Promise.resolve(x)`. Neither testing `construct` or SpeciesConstructor really tells you anything about `then`. It seems that the root problem here is trying to apply nominal type based reasoning to JS. Allen
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
