Other Promise methods use the value of the internal [[PromiseConstructor]] slot. The definition of Promise.prototype.then uses ordinary (mutable) "constructor" instead, in step 3. That should probably be changed to use the [[PromiseConstructor]] slot for consistency.
Re: http://people.mozilla.org/~jorendorff/es6-draft.html#sec-promise.prototype.then
This is as intended. The only other "methods" that use [[PromiseConstructor]] are `Promise.cast` (now `Promise.resolve`), which is specifically designed for allowing tamper-proof casting via private slots. `then` should use normal publicly-accessibly properties; compare e.g. `Array.prototype.map`.
Promise#then uses Promise Resolution Handler which uses [[PromiseConstructor]], is this expected to change?
In particular, for a has-resolution promise 'p', where p.[[PromiseConstructor]] = A and p.constructor = B and the resolved value is a thenable t:
p.then() will return a new promise 'b' of type B, then immediately enqueue a task which will create a promise 'a' of type A. It will then call t.then(resolve-of-a, reject-of-a) and a.then(resolve-of-b, reject-of-b).
I guess this makes sense, if you think of the public constructor property as "what type of promise do I want to return from then()" and the internal [[PromiseConstructor]] as "what type of promise do I want to create internally to handle promise chaining".
Just checking that this behavior is intentional.
Don't mean to be a pest, reopening just to ensure that domenic sees that Promise.then is actually specified currently to use *both* constructor *and* [[PromiseConstructor]]. Double-checking that this is intentional; feel free to close again if this really is the desired behavior.
https://github.com/domenic/promises-unwrapping/issues/73 might be related; perhaps the trusted "PromiseThen" implementation would use [[PromiseConstructor]] here?
That is a great point. Thanks for reopening. I will have to investigate further and make sure we have a consistent model here.
My guess is we will move to using `constructor` in the Promise Resolution Handler functions. But I will need to devote more time to it, soon.
Domenic,
Do you have an additional response to this, particularly given the availability of @@species.
I'd like to get this closed before wrapping up E6.
Thanks for the ping.
It looks to me after re-tracing the spec that the inconsistency here has been eliminated, probably via some of the refactorings that have happened over time.
The [[PromiseConstructor]] now only appear in the one place I thought it did (viz. Promise.resolve). And just to be sure, I also traced through the logic in comment #2 and found that these days only type B is involved---no promise of type A is created.
So I think this can be closed.
fixed sometime in 2014