And remove the existing Promise.resolve. Based on TC39 consensus reached yesterday. (No public pointer yet.) Down the road we can probably simplify the internal model due to this change as well, but I guess for now it's mostly important not to expose soon-to-be-legacy API.

According to <https://github.com/rwaldron/tc39-notes/blob/master/es6/2014-01/jan-30.md#conclusionresolution-3> and as noted in the es-discuss list, I think this change can now proceed and be uplifted to Aurora. In the unlikely case that a new consensus arises in the future for which "cast" is reintroduced, it will be easier to add a new method than remove an existing one. (The potential loss of the "resolve" optimization following the reintroduction of "cast" is an internal detail that would be transparent to all real-world consumers.)

Please consider a patch to make sure it reaches Aurora quickly. Promise was part of the highlight of the release notes: https://www.mozilla.org/en-US/firefox/29.0a2/auroranotes/

Comment on attachment 8373419 [details] [diff] [review] Rename Promise.cast to Promise.resolve. r=me

remote: https://hg.mozilla.org/integration/mozilla-inbound/rev/6b783305b12a

Comment on attachment 8373419 [details] [diff] [review] Rename Promise.cast to Promise.resolve. [Approval Request Comment] Bug caused by (feature/regressing bug #): DOM Promises User impact if declined: We'd ship a implementation that has just been obsoleted in the spec. Testing completed (on m-c, etc.): Yes Risk to taking this patch (and alternatives if risky): None, it's just dropping a method that we haven't shipped to anything beyond a Aurora String or IDL/UUID changes made by this patch: None

Do we have a bug to rehost/"nativize" in SpiderMonkey? Thanks for tracking the ES6 promises twists and turns here. /be

That is bug 911216. We don't really have a plan for that yet because we a) lack an event loop and b) the main benefit would be better subclassing support which we don't have yet.