Switch any/every/some to arrays instead of varargs

[domenic]

Back in #16, we ended up talking ourselves into using varargs. After seeing varargs in practice, I am now back in the array camp. Here's the essential reason:

// Promise.any with varargs (as it is now specced):

// - No []s in the arguments to Promise.any, but you need them in the onFulfilled handler.
Promise.any(a, b, c).then(([a, b, c]) => { });

// - Need ... in the arguments to Promise.any, but no adornments in the onFulfilled handler.
Promise.any(...array).then(array => { });

Instead I propose:

// Promise.any if it used arrays in both cases:

// - []s match
Promise.any([a, b, c]).then(([a, b, c]) => { });

// - no ...s on either side
Promise.any(array).then(array => { });

There's also the fact that the array methods that every and some take their name from are, well, array methods, and inextricably associated with arrays in my mind.

---

This is not a big deal in the end, as people can cope with some awkward asymmetry. But I think the parallel between what you pass in to the function vs. what onFulfilled gets called with is a good one to preserve, and breaking it makes things unnecessarily awkward. Thus I thought it'd be worth floating a fix to see how people feel.

[arv]

Promise.any(value).then((values) => { });
Promise.any([a, b, c]).then(([a, b, c]) => { });

What if value is an array already? There needs to be a way to distinguish these two cases.

[domenic]

@arv I don't understand the question? I wasn't proposing overloading them with both varargs and array; I was proposing only accepting array arguments. (Edited OP to try to make this clearer.)

[arv]

I see.

Would it throw for non Objects? Would {} be treated like [], just like the generic Array methods.

[domenic]

I think behaving like the generic array methods would make sense, yeah. It would reject with a TypeError for non-objects, and would [[Get]] the length property and use that to loop over. (The output would of course always be an array.)