I'm pretty sure you can get rid of readyPromise and just use readyList directly.

Do we want to keep the document context? It's another backwards-compatible but non-Promise "feature". And if we do keep it, there should be verifying assertions in test/unit/ready.js.

Perhaps we can leave that subject to change/undocumented. I don't want to verify it if we're going to change it in a future version.

I'm suggesting that we change it now, in both places.

Let's open another ticket then. This PR is already 2 tickets. I'd rather not hold it up. But I'm indifferent as to what context we use here. document still makes sense since it's the document ready handler.

This PR is the introduction of jQuery.ready.then... why start off on the wrong foot when we don't have to? It doesn't even make sense to create a ticket referencing behavior that hasn't landed. But I guess I'll put some text here just in case:

Per Promises/A+ and ES2015, then callbacks should be called without a this context. And although jQuery.Deferred#*With methods provide context to callbacks, we are moving in the direction of increased standards compliance, and should stop providing document context to jQuery.ready callbacks while we're already making backwards-incompatible changes to jQuery.ready.

I'm fine with not passing document, we just need to document that and the fact that it's async now. I can do that in the release notes once this lands.

@gibson042 The change wouldn't just affect jQuery.ready.then, and I'm familiar with the spec on Promises. Like you said, the document context is for back-compat, as we still have $(function(){}) and $(document).ready(), and while some may prefer Promise.resolve(jQuery.ready), I imagine that $(document).ready() and $(function() {}) will still be the most common, and a document context still makes sense to me on the latter 2. Like I said tho, I'm not opposed to changing that, but we don't have to change it now.

Ok, I can accept that: gh-3026.