Killing `Promise.fulfill`

Domenic Denicola domenic at
Wed Aug 21 15:36:35 PDT 2013

How about just `Promise`, following `String`, `Number`, `RegExp`, etc.?

(I tend to agree with Tab that both #a and #b should return a new promise. But we do need an easy coercion function, as Mark emphasizes.)

On Aug 21, 2013, at 18:31, "Mark S. Miller" <erights at<mailto:erights at>> wrote:

On Wed, Aug 21, 2013 at 3:16 PM, Tab Atkins Jr. <jackalmage at<mailto:jackalmage at>> wrote:
On Wed, Aug 21, 2013 at 1:57 PM, Mark S. Miller <erights at<mailto:erights at>> wrote:
> Excellent excellent! It seems we are in agreement and clarity on all
> terminology issue, and on almost complete agreement on substantive issues.
> The only remaining issue is whether either of the following expressions
> always return a fresh promise, and if they are exactly equivalent:
> a) Promise.resolve(v1)
> b) new Promise(r=>r.resolve(v1))
> When v1 is a promise,
> x) I prefer that #a return v1 and #b return a fresh promise that adopts v1.
> y) You prefer that both #a and #b return a fresh promise
> z) The fewest feasible allocations would have both return v1.
> w) I do not expect anyone will want #a to return a fresh promise and #b to
> return v1.
> We both agree that if we settle on either #y or #z, then #a and #b are
> equivalent. Otherwise they are equivalent up to this issue.
> The reason I prefer that #b return a fresh promise is that it is surprising
> for a "new" expression to return something other than a fresh object.

I think it's super bizarre for a class static to act differently from
the trivial desugaring to the same-named instance method.  (In this
case, it's not *quite* an instance method, but close enough.  ^_^  It
would be an instance method if we weren't caring about capability

> The reason I prefer #a is that the primary use case for #a is coercion --
> given possible promise v1, gimme a guaranteed genuine promise that
> designates the same (possibly eventual) non-promise. See calls to the Q()
> function at and
> (which corresponds
> to ). These calls are numerous
> and necessary, and sufficiently frequent that the extra transient allocation
> in the typical case will be a noticeable cost.

That's reasonable, but we should do it with a different function that
just promotes things into promises,

Good idea. As a coercing function, a natural name is Also, as a common coercer, brevity is a virtue.

or leave it to library code when
they need it.  (We don't, for example, have such an operation for
Array/Map/Set, though I have used such an operation before.)


es-discuss mailing list
es-discuss at<mailto:es-discuss at>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list