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

On Fri, Apr 13, 2018 at 3:33 AM Gus Caplan <> 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]:
> _______________________________________________
> es-discuss mailing list
es-discuss mailing list

Reply via email to