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 <[email protected]> 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 > [email protected] > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
