[strawman] Symbol.thenable proposal

Hello all, I just wanted to try and push this up again as this month's meeting approaches; I would love for this to get a champion and be discussed. -Gus On 2018-04-12 20:33:15, Gus Caplan wrote: > Hello all, > > In an effort to curtail the interesting behavior of Promise.resolve >

Re: [strawman] Symbol.thenable proposal

I don't see any problems with polyfills having to update, that's kinda how progress happens...On 17 Apr 2018 08:13, "T.J. Crowder" wrote:On Mon, Apr 16, 2018 at 6:36 PM, Tab Atkins Jr. wrote:>> I'm still strongly of the opinion that we messed

Re: [strawman] Symbol.thenable proposal

On Mon, Apr 16, 2018 at 6:36 PM, Tab Atkins Jr. wrote: > > I'm still strongly of the opinion that we messed this up... > Doing the reverse and letting > objects opt *out* of being treated as promise-like is probably the > most we can do at this point, unfortunately. I was

Re: [strawman] Symbol.thenable proposal

I think the purpose of this proposal is to *forbid* module authors from making their Module Record namespace object thenable, since doing that causes confusion. Setting a property on the function doesn't work when the "then" is inherited but the object still wants to be non-thenable; I think that

Re: [strawman] Symbol.thenable proposal

I agree with Tab that allowing developers to opt out of thenable behavior is the only recourse now, but I don't think `Symbol.thenable` is the best way to grant that power. In the case of module namespaces, since module authors cannot use `Symbol.thenable` as the name of an export, there's no way

Re: [strawman] Symbol.thenable proposal

On Fri, Apr 13, 2018 at 6:00 PM, Isiah Meadows 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

RE: [strawman] Symbol.thenable proposal

that's the protocol proposal i mention on my proposal repo (https://github.com/devsnek/proposal-symbol-thenable)-Gus___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

RE: [strawman] Symbol.thenable proposal

...@gmail.com> On Behalf Of Isiah Meadows Sent: Sunday, April 15, 2018 6:06 PM To: Claude Petit <p...@webmail.us> Cc: Jordan Harband <ljh...@gmail.com>; es-discuss <es-discuss@mozilla.org> Subject: Re: [strawman] Symbol.thenable proposal Not sure how this is relevant, since this i

Re: [strawman] Symbol.thenable proposal

classical OOP ¯\_(ツ)_/ ¯ But I might by "wrong" as > usual... > > -Original Message- > From: Isiah Meadows <isiahmead...@gmail.com> > Sent: Friday, April 13, 2018 9:01 PM > To: Jordan Harband <ljh...@gmail.com> > Cc: es-discuss <es-discuss@mozilla

Re: [strawman] Symbol.thenable proposal

This proposal is that Symbol.thenable can be false, or true (which is a no-op). A future proposal could make it *also* be a string or symbol (IsPropertyKey), and then change the method name. In other words, I don't think there's a conflict, and I think that changing the method name could and

Re: [strawman] Symbol.thenable proposal

It's a fair point, i assume the usage would be like if the property exists then ignore thenable behaviour and if it is falsy then none of any of this behaviour would occur, so a Module Namespace Object could have like [whateverSymbolName]: null, if thats sorta what you are proposing? On

Re: [strawman] Symbol.thenable proposal

A hypothetical proposal addressing that would intersect with this. On Sat, Apr 14, 2018 at 2:01 PM, wrote: > I don't understand why you would expect that, can you explain a bit more? > > -Gus > > On 14 Apr 2018 10:53, Michael Theriot > wrote: > >

Re: [strawman] Symbol.thenable proposal

I don't understand why you would expect that, can you explain a bit more?-GusOn 14 Apr 2018 10:53, Michael Theriot wrote:Currently 'then' is effectively a reserved key and I'd expect any extension that allows the language to ignore it likewise include a means of

Re: [strawman] Symbol.thenable proposal

Currently 'then' is effectively a reserved key and I'd expect any extension that allows the language to ignore it likewise include a means of changing the key entirely. On Apr 12, 2018, at 9:33 PM, Gus Caplan wrote: Hello all, In an effort to curtail the interesting behavior of

Re: [strawman] Symbol.thenable proposal

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

Re: [strawman] Symbol.thenable proposal

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

Re: [strawman] Symbol.thenable proposal

`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,

Re: [strawman] Symbol.thenable proposal

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

[strawman] Symbol.thenable proposal

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