Killing `Promise.fulfill`

Tab Atkins Jr. jackalmage at
Wed Aug 21 15:44:30 PDT 2013

On Wed, Aug 21, 2013 at 3:36 PM, Domenic Denicola
<domenic at> wrote:
> On Aug 21, 2013, at 18:31, "Mark S. Miller" <erights at> wrote:
>> Good idea. As a coercing function, a natural name is Also,
>> as a common coercer, brevity is a virtue.
> 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.)

Yeah, that's the existing coercer idiom.  The other one that's close
is Array.from().  It still always produces a new object, but that
doesn't necessarily have to be a property of every class's usage.

But I like just Promise(), sans "new".

Also, while we've settled on "resolve" still retaining its current
semantics (promises get adopted, other values just fulfill the promise
directly), I think the other part of Domenic's proposal - removing
"accept" from the resolver - is still reasonable.  There's no
behavioral difference between resolving and accepting for .then(), so
we don't need it there, and you already need to be careful that your
value is wrapped in a promise for .flatMap() callbacks, so requiring
the same for the resolver function when those are the semantics you
want is fine with me.

We'll still need the class static for it, just not the resolver
function.  I propose we quit with the synonyms, and use Promise.of()
like I (and others) proposed a long time ago.  ^_^


More information about the es-discuss mailing list