Re: Differences between Promise.prototype methods with regard to what constitutes what constitutes compatible receiver

That seems reasonable, although I'm not sure of the value of that consistency. It'd have to be proven to be web-compatible - ie, if anyone was adding a `.then` to a primitive prototype, they might be relying on the current behavior of `.catch`. On Fri, Jul 20, 2018 at 9:58 PM, Darien Valentine wr

Re: Differences between Promise.prototype methods with regard to what constitutes what constitutes compatible receiver

That makes sense for sure, but I don’t think subclassing is impacted by receiver constraints in this regard either way, since subclasses will still be “IsPromise” promises. What is affected is portability of the methods to “non-IsPromise” thenables. Catch not requiring an IsPromise receiver makes s

Re: Differences between Promise.prototype methods with regard to what constitutes what constitutes compatible receiver

This is intentional - `catch` delegates to `then`, so that a subclass that overwrites `then` doesn't have to also override `catch` (and the same for `finally`, which also calls into `then`). On Fri, Jul 20, 2018 at 4:29 AM, Darien Valentine wrote: > In `Promise.prototype.then`: > > > 1. Let prom

Differences between Promise.prototype methods with regard to what constitutes what constitutes compatible receiver

In `Promise.prototype.then`: > 1. Let promise be the this value. > 2. If IsPromise(promise) is false, throw a TypeError exception. > [ ... ] In `Promise.prototype.finally`: > 1. Let promise be the this value. > 2. If Type(promise) is not Object, throw a TypeError exception. > [...] In `Promise.