Viable?

[gibson042]

Given the abundance of userland promise libraries, is there really a feasible way to un-poison "then"? Having some consumers treat a value as thenable and others not seems worse than just abandoning the property name, placing it in a class with "__proto__" and (in DOM land) form element names that shadow <form> element properties.

[ljharb]

I'm not sure what you mean; all the userland libraries have then forever until they add this Symbol.

The intention isn't that a promise lib would ever add the symbol; it's that a non-promise lib could have a .then method along with the Symbol.

If you mean that userland promise libs wouldn't respect the symbol; I'm pretty sure they'd all do it super rapidly considering that not doing so would make them broken wrt native Promises.

[gibson042]

If you mean that userland promise libs wouldn't respect the symbol; I'm pretty sure they'd all do it super rapidly considering that not doing so would make them broken wrt native Promises.

Yes, that's the situation I'm talking about... the very same value (i.e., an object with both a then method and a Symbol.thenable property) would be treated as non-thenable by "new" consumers but thenable by today's consumers—some of which have quite long usage tails (e.g., people still open issues for five-year-old versions of jQuery).

[ljharb]

Since that wouldn't break old code, only new usages of old code (except for the hopefully super-rare case of resolving a promise with a Module namespace object), I don't anticipate that will cause problems in practice.

[devsnek]

hopefully people who think "i want to use this new symbol" also think "i realise this promise polyfill i downloaded five years ago doesn't know about this symbol so i'll need to update"

[gibson042]

You can't assume that those groups of people are the same. Defensively-written libraries must avoid defining Promise-incompatible "then" methods, with or without a new symbol.

[ljharb]

@gibson042 that's totally true! that simply means that the symbol itself won't be useful for defensively-written libraries across the wider ecosystem for awhile, until all the libs and engines support it - which is all the more reason to start that clock as soon as possible :-D

[ljharb]

Closing, because this is viable from a userland perspective - or at least, this was nobody on the committee's concern.