<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Apr 29, 2015, at 8:44 AM, C. Scott Ananian wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Apr 29, 2015 at 1:06 AM, Brendan Eich <span dir="ltr"><<a href="mailto:brendan@mozilla.org" target="_blank">brendan@mozilla.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Kevin Smith wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
So what would the ideal Promise.resolve semantics do?  I'm not sure, maybe use SpeciesConstructor instead of [[PromiseConstructor]]?<br>
</blockquote>
<br>
This removes the wart in my view, has no less integrity. C. Scott?</blockquote><div><br></div><div>Making this concrete, here would be the new text for 25.4.4.5 Promise.resolve(x):</div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">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.<br>1. Let C be the this value.<br>2. If IsPromise(x) is true,<br>    a. Let constructor be the value of SpeciesConstructor(x, %Promise%)</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">    b. If SameValue(constructor, C) is true, return x.<br>3. If Type(C) is not Object, throw a TypeError exception.<br>4. Let S be Get(C, @@species).<br>5. ReturnIfAbrupt(S).<br>6. If S is neither undefined nor null, let C be S.<br>7. Let promiseCapability be NewPromiseCapability(C) </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">[...remainer elided...]</blockquote><div> </div></div><div>Step 2a is the only change.  (It was previously "Let constructor be the value of x's [[PromiseConstructor]] internal slot.")</div></div></div></div></blockquote><br></div><div>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`.</div><div><br></div><div>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.</div><div><br></div><div>Allen</div><br></body></html>