On Fri, Dec 20, 2013 at 5:02 AM, Andreas Rossberg <rossberg at google.com>wrote:

> On 19 December 2013 23:29, Alex Russell <slightlyoff at google.com> wrote:
> > Right, but number of objects you have to guard with anti-branding is
> much,
> > much larger. That argues against thenables pretty strongly, but again, I
> > don't think we need to change anything for ES6. We can repair this in
> ES7 if
> > it's a problem in practice.
>
> I highly doubt that will be possible -- experience strongly suggests
> that every odd feature _will_ be relied on in the wild by that time.
> If we think thenable assimilation is a problem then we have to remove
> it now. I, for one, would welcome that. We could still provide an
> _explicit_ thenable adaptor method in the Promise API.
>

We can create an alternative to .then() at some future point. You're right
that if we continue to pile into the misbegotten .then() clown car, all is
lost for all time, but I don't think that's our only hope.

Anyhow, what's done is done. Promises for ES6 are *done* and we need to get
on with understanding our options in that world.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20131220/456aa108/attachment.html>

On Fri, Dec 20, 2013 at 5:02 AM, Andreas Rossberg <rossberg at google.com>wrote:

> I highly doubt that will be possible -- experience strongly suggests
> that every odd feature _will_ be relied on in the wild by that time.
> If we think thenable assimilation is a problem then we have to remove
> it now. I, for one, would welcome that. We could still provide an
> _explicit_ thenable adaptor method in the Promise API.

We can create an alternative to .then() at some future point. You're right
that if we continue to pile into the misbegotten .then() clown car, all is
lost for all time, but I don't think that's our only hope.

Anyhow, what's done is done. Promises for ES6 are *done* and we need to get
on with understanding our options in that world.