I don't see any problems with polyfills having to update, that's kinda how progress happens...
On 17 Apr 2018 08:13, "T.J. Crowder" <[email protected]> wrote:
On Mon, Apr 16, 2018 at 6:36 PM, Tab Atkins Jr.<[email protected]> 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:```jssomeThirdPartyPromise.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). Notes:* `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 = trueAgain, that's where I ran into the wall above, which I think impacts Symbol.thenable = false as well.-- T.J. Crowder
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
