<div dir="ltr">First, "q = Promise.fulfill(p)" never made any sense, as if p is pending, then q cannot be fulfilled -- there's no non-promise value to fulfill it to. Remember, a promise is fulfilled when it's (original) .then would invoke its first (onFulfilled) callback. "fulfilled", "rejected", "pending" are at the .then level of abstraction.<div>
<br></div><div>At the .flatMap level of abstraction, the fulfill-like concept is "accept". Promise q accepts value (whether promise or non-promise) v when q's (original) .flatMap would invoke its first (onAccept) callback. "accept" is fully parametric, at the .flatMap level of abstraction, where "fully parametric" is meaningful.</div>
<div><br></div><div>So, except for the name of the old operation we're no longer using, I agree with Domenic. It is not that we renamed "Promise.fulfill" to "Promise.resolve", we killed "Promise.fulfill" because it was incoherent, and we renamed "Promise.accept" to "Promise.resolve". </div>
<div><br></div><div>For people concerned only about the .then level of abstraction, I see little reason to ever use Promise.resolve rather than Promise.cast, and much reason to prefer Promise.cast. But fwiw we did agree to express the difference now, to be perceived by future and experimental uses of .flatMap in the future.</div>
<div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jan 28, 2014 at 10:20 AM, Juan Ignacio Dopazo <span dir="ltr"><<a href="mailto:jdopazo@yahoo-inc.com" target="_blank">jdopazo@yahoo-inc.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="font-size:10pt;font-family:HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif"><div class="im">
<div><span style="font-family:Arial;font-size:13px">On Tuesday, January 28, 2014 10:13 AM, Kevin Smith <<a href="mailto:zenparsing@gmail.com" target="_blank">zenparsing@gmail.com</a>> wrote:</span><br></div></div><div style="display:block">
<div style="font-family:HelveticaNeue,'Helvetica Neue',Helvetica,Arial,'Lucida Grande',sans-serif;font-size:10pt"><div style="font-family:HelveticaNeue,'Helvetica Neue',Helvetica,Arial,'Lucida Grande',sans-serif;font-size:12pt">
<div dir="ltr"> </div>  <div><div><div></div><div><div dir="ltr"><div><div><div class="im"><blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br clear="none">
My take is that the difference between "cast" and "resolve" is so<br clear="none">
subtle that I don't think it captures developer intention. In<br clear="none">
other words, if I see some code calling Promise.cast(otherPromise),<br clear="none">
I can't be sure that the developer made an intentional choice over<br clear="none">
Promise.resolve(otherPromise).</div><br clear="none"></blockquote><div><br clear="none"></div><div>Note that `Promise.resolve(p)`, where p is a promise, does *not* return an eventual for the eventual value of p.  Rather, it returns an eventual for p, literally.  Promises should be considered fully parametric (in other words, nestable).</div>

<div><br></div></div><div><div style="color:rgb(34,34,34);font-family:arial;font-size:small">That's not true as per the last consensus. There was `Promise.fulfill(p)` which would've nested promises, but it was left for ES7 to investigate fulfill+flatMap.</div>
<span class="HOEnZb"><font color="#888888"><div style="color:rgb(34,34,34);font-family:arial;font-size:small"><br></div><div style="color:rgb(34,34,34);font-family:arial;font-size:13px">Juan</div></font></span></div><div>
<br></div></div></div></div></div></div></div>  </div> </div>  </div> </div></div><br>_______________________________________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br>    Cheers,<br>    --MarkM
</div>