Re: [heycam/webidl] Some things do not seem sound in “react to a Promise<T>” (#943)

> Previously the first issue was discussed [...]

Apologies, didn’t realize I was duplicating. Thanks for linking it.

> [Re: second issue] Are there specific specs where you can see there being a problem with the current behavior?

As far as I know, there are no specs where the current behavior is a problem. This is because every usage I found of a `Promise<T>` type where a conversion from ES would take place was one of:

- `Promise<undefined>`
- `Promise<any>`
- `Promise<Response>` (interface)

For all three of these cases, the inner type’s conversion algorithm is one which is guaranteed to never invoke arbitrary ECMAScript code and to return the same result value. If there’s a requirement that `Promise<T>` can only be used with an inner type that exhibits these properties, then the current “react to” steps seem fine (apart from the fact that _failed_ conversions produce different ES values each time, but that’s kinda tied up with the earlier stuff).

I don’t think there’s a requirement like that, though. Should there be? The duplication would cease to be theoretical the first time someone specs an operation to consume e.g. `Promise<DOMString>` and writes both “upon rejection” and “upon fulfillment”, since as currently written, if the ES value were `{ i: 0, toString() { this.i++ } }`, the ES value now looks like `{ i: 2, ... }` (and different values/completions could be produced each time).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/heycam/webidl/issues/943#issuecomment-740419739