Calling resolve twice is not specified about promises-tests

[ForbesLindesay]

It should be 'bar', based on ES6 promise specs and the draft for promises/A+ - constructors, however, this isn't actually specified by promises/A+ because promises/A+ only specifies the behavior of .then. If all you specify is the behavior of .then, it is impossible to distinguish between the two options. That's why this test suite probably doesn't check that case.

[lgalfaso]

@ForbesLindesay well, I think it can be specified if the spec defines the interaction between the resolution process and the promise status changes (say from pending to fulfill)

[domenic]

Yeah, this seems more related to the fact that Promises/A+ doesn't define how promises must relate to each other. E.g. you could envision a 1.2 revision that had something like:

"If promise A is fulfilled before promise B, then all of promise A's handlers must be called before promise B's handlers"

or something. The constructor spec would define how/when promise A or promise B can be fulfilled.

[domenic]

I'm going to rename this issue to be a bit more descriptive and tag it/milestone it. We may want to consider a 1.2.

[ForbesLindesay]

@lgalfaso That resolution process is not defining the resolve method, it is defining the internal process undertaken when a promise is returned from .then. It is not possible to return two values from a function, so I don't think this case can ever occur like that.

[ForbesLindesay]

@domenic I think we really need to get the constructors spec finished, then we can just point to it and say "this is covered by the Promises/A+ Constructors spec (and corresponding tests)". I don't think this case is about the ordering of promise resolution as you suggest, because in the example, that order is fully deterined. p1 is first made to follow p2, then p2 is fulfilled, then p1 is fulfilled because it is following p2. The second call to p1.resolve is ignored, according to the constructor spec, but I don't think you can specify that it should be ignored within the confines of only specifying the behavior of .then.

[domenic]

@ForbesLindesay you are right. We don't really specify the ordering of handlers, but this particular issue is indeed about whether the second call should be ignored or not.

[ForbesLindesay]

I also don't see how we could specify the ordering of handlers when given two different promise implementations. We could consider doing so within a given implementation I suppose, but I'm not sure it has that much value.

[lgalfaso]

Thanks for the info and as long as it is known that it is undefined what the behavior should be, then I am ok