[strawman] Symbol.thenable proposal

[Guy Bedford]

It's worth noting that the driving use case here is coming from NodeJS
development hitting issues where the guaranteed result for dynamic import
resolution can't be assumed to be a module namespace, although please
correct me if I'm wrong here Gus.

Alternatively could this mitigation be handled by creating a
`Promise.resolveStrict` primitive that explicitly opts-out of thenable
resolution in the promise chain?

I'd think we are getting further and further away now from third-party
promise implementation interops, that such approaches might make sense to
consider at this point, in the name of returning to more well-defined
semantics.

On Fri, Apr 13, 2018 at 3:33 AM Gus Caplan <me at gus.host> wrote:

> Hello all,
>
> In an effort to curtail the interesting behavior of Promise.resolve
> (especially
> with regard to dynamic import), I have created a proposal for a well-known
> symbol which will allow an object to not be treated as a "thenable."
>
> I am privy to the current protocol proposal which might be a better fit for
> this, but due to dynamic import already being stage 3, I don't feel we
> should
> wait for it to come to fruition.
>
> Comments and suggestions are of course quite welcome at the repo [1].
>
> Thanks,
> -Gus
>
> [1]: https://github.com/devsnek/proposal-symbol-thenable
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180413/4d58a72d/attachment.html>