> Can you leave what you feel is the best solution aside for a moment and
>> comment on this proposal instead?
>
>
>
We don't want anti-branding because that puts the "burden of proof" in the
wrong place.  I would only consider it if (a) some kind of branding is
absolutely required, and (b) there is absolutely no other option.

The problem with "branding" in general is that TC39 has decided, for better
or worse, that duck-typing of this kind is going to be done with symbols.
 And symbols aren't really pollyfillable.

My recommendation to TC39 would be to remove thenable coercion from the
Promise design and inform library authors that they need to subclass the
Promise type if available.  If it turns out that library authors are unable
to do so, then add coercion back to the design.

This research can be done within a couple of weeks, I would think.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20131221/db61939f/attachment.html>

> Can you leave what you feel is the best solution aside for a moment and comment on this proposal instead?

We don't want anti-branding because that puts the "burden of proof" in the
wrong place.  I would only consider it if (a) some kind of branding is
absolutely required, and (b) there is absolutely no other option.

The problem with "branding" in general is that TC39 has decided, for better
or worse, that duck-typing of this kind is going to be done with symbols.
 And symbols aren't really pollyfillable.

My recommendation to TC39 would be to remove thenable coercion from the
Promise design and inform library authors that they need to subclass the
Promise type if available.  If it turns out that library authors are unable
to do so, then add coercion back to the design.

This research can be done within a couple of weeks, I would think.