[strawman] Symbol.thenable proposal

[Guy Bedford]

To state even more clearly how this is directly affecting API decisions in
NodeJS, we're considering supporting a dynamic import hook for `vm.Script`,
and one of the API suggestions is:

new vm.Script(`import('x').then(x => console.log(x))`, {
  async resolveDynamicImport (specifier) {
    return getNamespacefor(specifier);
  }
});

The issue here being that this API is guaranteed to result in an error for
module namespaces exporting a `then` function.

Yes, effectively not allowing variable dictionary object returns in
promise-based APIs becomes the fix, but this does seem a rather arbitrary
restriction on API development.

I think the proposal here would be a much-needed addition to be able
lock-down guarantees in scenarios such as this.

On Sat, Apr 14, 2018 at 3:00 AM Isiah Meadows <isiahmeadows at gmail.com>
wrote:

> I can't remember where, but I recall seeing this discussed elsewhere
> (maybe in the TC39 meeting notes?) and the conclusion was basically
> ¯\_(ツ)_/¯. I'm not convinced myself it's actually worth the extra
> symbol just to make something not considered a thenable - all these
> Promise libraries have been able to get away with it for this long;
> what makes ES promises any different here? (Dynamic import is probably
> the only possible case I can think of short certain proxies in terms
> of things that could be considered thenables but shouldn't always.)
>
> Worst case, you can just return a value that happens to have a promise
> in a property, like in `{value: somePromise}` - nobody resolves that
> except `co` IIRC.
> -----
>
> Isiah Meadows
> me at isiahmeadows.com
>
> Looking for web consulting? Or a new website?
> Send me an email and we can get started.
> www.isiahmeadows.com
>
>
> On Fri, Apr 13, 2018 at 4:20 PM, Jordan Harband <ljharb at gmail.com> wrote:
> > `await import(path)` wouldn't ever be able to do anything besides
> > Promise.resolve; I'm pretty confident that this proposal, or something
> like
> > it, is the only possibility to make ModuleRecords (for modules that
> export a
> > `then` function) not be considered thenable.
> >
> > On Fri, Apr 13, 2018 at 8:02 AM, Guy Bedford <guybedford at gmail.com>
> wrote:
> >>
> >> 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
> >>
> >>
> >> _______________________________________________
> >> es-discuss mailing list
> >> es-discuss at mozilla.org
> >> https://mail.mozilla.org/listinfo/es-discuss
> >>
> >
> >
> > _______________________________________________
> > 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/20180414/cac0c996/attachment.html>