[strawman] Symbol.thenable proposal
tj.crowder at farsightsoftware.com
Tue Apr 17 13:13:55 UTC 2018
On Mon, Apr 16, 2018 at 6:36 PM, Tab Atkins Jr.
<jackalmage at gmail.com> wrote:
> I'm still strongly of the opinion that we messed this up...
> Doing the reverse and letting
> objects opt *out* of being treated as promise-like is probably the
> most we can do at this point, unfortunately.
I was going to play devil's advocate here ("Is it **really** too late?
Probably, but we should at least explore it..."), toying with the idea of a
more strict kind of promise (I called it NativePromise), but I ran into a
wall which may affect Symbol.thenable = false as well:
someThirdPartyPromise.then(() => import("foo")).then(/*...*/);
That converts the promise from `import()` (which understands
Symbol.thenable = false) into a non-native Promise, and thus triggers the
bug Symbol.thenable is meant to resolve, since when `import()`'s promise
resolves, it hands a thenable to the 3rd-party promise that doesn't handle
Symbol.thenable = false. Boom.
How does this proposal address that? Because if it doesn't, and third-party
libs are supposed to update to support Symbol.thenable = false, we should
at least discuss making promises opt-in via Symbol.thenable = true for a
special class or type of promise.
My thought (which, again, ran into the wall above) was: Add a new type of
promise (call it NativePromise) which doesn't support thenables, just
objects with Symbol.promise = true (note I didn't call it "thenable"). (I
also toyed with well-known symbols for `then`, `catch`, and `finally`
instead, but that's probably overkill). All language-generated and
host-provided promises would be NativePromises (this would be a breaking
change for `async` functions, thus impact assessment would be required).
* `import()` would use NativePromise and thus not be confused by a module
exporting a `then` function
* NativePromise would be thenable
* Promise would continue to support thenables
* NativePromise would not, and thus would not be Promises/A+-compliant
* NativePromise and Promise would be fully interoperable (both would have
Symbol.promise = true and `then`)
* Actively-maintained 3rd-party promise libs like Bluebird would implement
Symbol.promise = true to get full interoperability with NativePromise
* NativePromise would only have one-way interoperability with any 3rd-party
lib that didn't implement Symbol.promise = true
Again, that's where I ran into the wall above, which I think impacts
Symbol.thenable = false as well.
-- T.J. Crowder
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss