From: es-discuss <es-discuss-bounces at mozilla.org> on behalf of Brendan Eich <brendan at mozilla.com>

> Quildreen Motta wrote:
>> If that's correct, I don't see any use cases for Promise.resolve right now, unless a library where to provide a corresponding unspecified `flatMap` implementation.
>
> IIRC (and I may not; endless promises threads make me sleepy) this is the reason to have Promise.resolve: to enable some to blaze the flatMap trail ahead of ES6.

Kind of. Since `Promise.resolve(x)` is just `new Promise(resolve => resolve(x))`, the only reasons for including that shorthand method are symmetry and the idea that this operation might be common enough to necessitate a shorthand. See my earlier reply.

On the other hand, that *is* part of the reason we moved all the unwrapping to the `then` side---as Mark puts it, using the "accept" operation instead of "resolve," albeit while still using the "resolve" name. (Which is pretty confusing when you try to explain it, but I swear, it makes sense...)

Kind of. Since `Promise.resolve(x)` is just `new Promise(resolve => resolve(x))`, the only reasons for including that shorthand method are symmetry and the idea that this operation might be common enough to necessitate a shorthand. See my earlier reply.

On the other hand, that *is* part of the reason we moved all the unwrapping to the `then` side---as Mark puts it, using the "accept" operation instead of "resolve," albeit while still using the "resolve" name. (Which is pretty confusing when you try to explain it, but I swear, it makes sense...)