[strawman] Symbol.thenable proposal

Isiah Meadows isiahmeadows at gmail.com
Sat Apr 14 01:00:36 UTC 2018


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
>


More information about the es-discuss mailing list