Edit: fixed link to point to Chris's post, not the whole thread.
@Chris_Lattner3 shared his thoughts on my other thread (about potential implementation-level details of this feature), suggesting that we might want to treat a variadic generic like a standard generic type with the addition of being constrained to be a tuple.
This made my think that we may widen / shift the focus a little bit, and instead of variadic generics we might want to introduce variadic tuples altogether. This means that the syntax (...T) is (maybe) not limited to appear in generic contexts but may be used "anywhere" to indicate a tuple of variadic length. In this way a variadic generic type is simply a type which has one (or more?) generic parameters which are variadic tuples, so that with this shift in focus we are at least getting the same functionality for free.
struct Variadic<A, B, (...Collections: Collection)> {
[...]
var collections: Collections
}
We have then to decide how code referring to a variadic tuple works. For example, considering the previous example in which Collections is constrained to the Collection protocol, we might allow calls to members of Collection to be applied to the collections variable in order to return a tuple containing the result of applying the member to all of the tuple elements, or in code:
extension Variadic {
func interestingFunc() {
// the next statement is equivalent to the following:
// (collections.0.first, collections.1.first, collections.2.first, ...)
var firstElements = collections.first
[...]
}
}
What do you think?