Address #51: when_all/when_any result type

[K-ballo]

First draft (not entirely happy with it):

• Fixed return types.
• Adjusted requirements (should accept any of future<R>, future<R>&, shared_future<R>, shared_future<R>&, shared_future<R> const, shared_future<R> const&),
• Added when_any and when_any_back to synopsis.

Notes:

• I fixed the inconsistent use of typename/class for these functions, but there are several other cases to take care of.
• The wording makes use of both "first/second overload" and "first/second signature", it should be consistent (my vote goes to "overload").
• I was surprised to see there's a variadic overload of when_any_back, since it cannot do anything differently than when_any. Was it introduced for symmetry? If so, I would suggest to be very explicit and spell out that the effects are equivalent to when_any.

[arturl]

Thanks, I'll take a look.
when_any_back(f1,f2) will produce a tuple in which the ready future will appear at position 1. What's the problem with this?

[K-ballo]

When when_any_swapped was introduced, it was only meant to deal with iterators. IIRC, the consensus was that a variadic overload was not worth the trouble since it can only work in limited scenarios, and the number of arguments to check is small anyways.

when_any_back(f1,f2) will produce a tuple in which the ready future will appear at position 1. What's the problem with this?

In order for that to be implementable, the decayed type of f1 and f2 has to be the exact same, so that we can put either of them at any position in the resulting tuple. It doesn't work for the general case, say if f1 is future<int> and f2 is future<void>. What's supposed to happen in that situation?

[arturl]

Right, the types of f1 and f2 must be the same for this to work. This weakens the argument for consistency with when_any.

[K-ballo]

My wording does not reflect this, and now I'm starting to fear that the intention of the current wording is to have some kind of movable initializer_list. I will have to think about this some more. We should at least be very clear about the intention, we can always defer precise wording to LWG.

[arturl]

@K-ballo: merged, thanks!

[K-ballo]

Ok, but keep in mind that this wording still doesn't cover the intent, at least for when_any_back. I'm still unsure as to what the intent is/was for when_all and when_any.