So is this good to go other than the enhancement @gibson042 suggested? I am thinking we should land it as-is and can do that part later.

I'd also like to test in on real browsers and not in Node via jsdom; I plan
to do it. It can be done later, though, I don't want to delay it further.

I apologize for letting this response sit so long, and for its incompleteness, but—the perfect being the enemy of the good—have decided to post it anyway.

We need to get on the same page with respect to a few dimensions of compatibility:

• Backwards
  • Do we remove our .then extensions?
  • Do we change the meaning of new jQuery.Deferred().resolve( thenable )?
• Forwards
  • Do we undeprecate .pipe?
• Spec
  • Do we let deferreds break irreparably on code like dfd.done( thrower ).then( neverCalled, neverCalled ); dfd.resolve()?

This PR proposes keeping all old behavior in .pipe and reducing .then to a by-the-spec implementation. After digesting it, I think more conversation is merited on all of the above points before accepting anything. I've put my work on hold to address them.

For the record, it is possible to preserve all .then extensions with the possible exception of context-setting. I'd personally like to do so, perhaps with deprecation, remove the already-deprecated .pipe, and fix the "broken forever" case.

Thoughts?

What are ".then extensions"?

Functionality exposed by jQuery that is not in the spec:

• Multi-valued fulfillment and rejection
• Contextual (this-providing) fulfillment and rejection
• Progress callbacks

Thanks. I take it that by "the spec" you mean Promises/A+, not ES6.

I take it that by "the spec" you mean Promises/A+, not ES6.

We generally do mean ES6, but it's complicated by the fact that testing is against Promises/A+.

Hmm, yeah, if you wanted to pass the test262 tests for promises, then none of those would be feasible, since e.g. per ES6 onFulfilled/onRejected are only called with one argument, and .then only accepts two arguments, and so on.

Directly in the suite? As far as I can tell, the ES6 draft leaves unspecified what happens in those "extended" scenarios:

• https://people.mozilla.org/~jorendorff/es6-draft.html#sec-promise.prototype.then
• https://people.mozilla.org/~jorendorff/es6-draft.html#sec-rejectpromise
• https://people.mozilla.org/~jorendorff/es6-draft.html#sec-fulfillpromise
• https://people.mozilla.org/~jorendorff/es6-draft.html#sec-rejectpromise

Yes, directly in the suite. For example arguments are passed to onFulfilled and onRejected by the line

Let status be the result of calling the [[Call]] internal method of promiseCapability.[[Reject]] passing undefined as thisArgument and (handlerResult.[[value]]) as argumentsList.

which notably does not allow passing more than one argument.

That implements "the job PromiseReactionJob with parameters reaction and [one] argument" (https://people.mozilla.org/~jorendorff/es6-draft.html#sec-promisereactionjob), which is called by either a two-argument then or single-valued fulfill/reject.

The extra-argument versions appear to exist in an extra-specification domain, and are arguably compatible with it. At any rate, they would be required for perfect backwards compatibility within jQuery.

The point is that the then method is specified as only having two arguments, and any other arguments must be ignored. They certainly can't change the behavior of then to be something different than specified.

I agree jQuery cannot be backward compatible with itself and also compatible compliant with ES6.

It's not really surprising that any deviation from what the Promise object in browsers does makes a particular implementation incompatible. After all, ES6 goal is to specify everything in enough detail that any differences between implementations are unobservable. jQuery Deferreds have to be distinguishable from ES6 Promise for back compat so perfect compliance is impossible.

The Promises/A+ spec compliance is the best we can hope for here IMO.

As discussed in the jQuery core meeting today, my goal is adhering to spec for code that colors inside the lines but using the rest of the space for maximum backwards compatibility:

Spec compat:

• Don't swallow resolution: dfd.done( thrower ).then( expectsInvocation ); dfd.resolve()

Back compat:

• Don't process resolution values: dfd.resolve( thenable ).done( expectsThenable )
• Multi-valued resolution: dfd.resolve( value1, value2, ... ).then( expectsMultipleArguments )
• Progress: dfd.notify( progress ).then( null, null, expectsInvocation )

Possible conflict:

• Contextual resolution: dfd.resolveWith( context, values ).then( expectsContext )

So I will be putting a PR together after all.

   raw     gz Compared to master @ d7e5fcee519e5f3e840beef9e67a536e75133df9
 +1769   +478 dist/jquery.js
  +629   +235 dist/jquery.min.js

100% Promise A+ compliant, smart interoperability (even .pipe() can handle standard promises).

Does not protect against exceptions in non-then handlers like #1996, which does so at the cost of nearly doubling memory usage (not worth it imo).

Would appreciate some code review too.

... and I f***ed up the whole PR pretty badly so any help in handling this mess by some git guru would be much appreciated :/

This PR was essential in working out which changes we wanted to make and how to make them. So, it's not a complete waste, but since we will be landing #1996, this one can be closed.