Strong promises instead of nonstandard Promise extensions?

[Domenic Denicola]

As we know, V8 has a number of non-standard promise extensions, which have not even been proposed to TC39. This has caused some angst as it leads to the usual problem of causing Chrome-only sites like Inbox to arise. However, the V8 team has stated they currently have no intention of removing the non-standard extensions, because they will be important for a type system.

This got me thinking, that perhaps the non-standard extensions could be introduced as behavior changes in strong mode? That is, just like strong arrays have different semantics in a large variety of ways, strong promises could have different semantics for their .then and .resolve methods, instead of introducing nonstandard .chain and .accept.

This seems much better than the current situation in many ways. Not only would it avoid shipping non-standard extensions with all the web dangers that implies, but it would also guarantee that in strong mode promises can be typed as desired. And IMO it fits well with strong mode's philosophy of "mostly compatible, if you don't do something edge-casey," again similar to strong arrays.

[Sébastien Doeraene]

Hi Domenic,

Unless I am mistaken:

Although I would very much like to see typeable methods on Promises, this would actually not fit with strong mode's philosophy, which is not "mostly compatible" but "compatible as long as it works (without exception) in strong mode". Your proposal would create cases where something works without exception in strong mode, but doesn't behave the same in weak mode. This is not acceptable according to strong mode's policy.

Cheers,

Sébastien

--
You received this message because you are subscribed to the Google Groups "Strengthen JS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to strengthen-j...@googlegroups.com.
To post to this group, send email to streng...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/strengthen-js/45b17f7e-5318-4e26-94fc-0b4d744c57e1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Domenic Denicola]

From: Sébastien Doeraene [mailto:sjrdo...@gmail.com]

> Although I would very much like to see typeable methods on Promises, this would actually not fit with strong mode's philosophy, which is not "mostly compatible" but "compatible as long as it works (without exception) in strong mode". Your proposal would create cases where something works without exception in strong mode, but doesn't behave the same in weak mode. This is not acceptable according to strong mode's policy.

Hmm, I do not really understand. Can you give an example of such code? And can you show how it is different from strong arrays, which have similar scenarios?

[Sébastien Doeraene]

Hi,

Take .chain, for example, which, IIRC, is like .then but does not resolve recursively a Promise returned by the callback. This method can be typed as:
Promise.chain :: (Promise(a)) => (a → Promise(b))

(as pointed by Andreas at https://esdiscuss.org/topic/promise-cast-and-promise-resolve#content-12, under the name flatMap)

If you modify .then in strong mode to behave like .chain, then the following code works find in strong mode, but breaks in weak mode:

const p = new Promise(function(resolve, reject) {

  const innerP = new Promise(function(resolve2, reject2) {

    resolve2(42);
  }));
  resolve(innerP);

});

a.then(b => b.then(x => console.log(x)));

since in strong mode, b will be the Promise `innerP`, which has a `then` method; whereas in weak mode, b will be the flattened value 42, which does not. The call to b.then() will therefore throw in weak mode, whereas it works as intended in strong mode.

Cheers,

Sébastien

[Domenic Denicola]

I think I see. It is only OK if semantics change such that strong versions throw errors (or ignore the operation, in sloppy+strong). Or if they change such that reflective operations reveal different results. But it is not OK if the semantics change such that they give different results for normal non-reflective operations. That does seem to kill this proposal. (Or any similar proposals, like making .accept/.chain only available in strong mode.)