Wow, that’s pretty.
Awesome, this whole explanation clarified my understanding and especially in light of the fact this is an advanced feature anyway I find your justification entirely satisfying.
If I’ve understood correctly, the reality of the reasoning matches the essence of what I was getting at in my question quoted below, although with your clarifications I see that my description could not be said to be correct as written.
Thank you for the detailed explanation! Maybe I will just have to let it sink in, but initially I just don’t have the same intuition as you, because to me your hypothetical expanded version of the List struct would read more naturally as:
struct List<Int, String, Bool> {
let elements.0: Int
let elements.1: String
let elements.2: Bool
}
It does feel like a closer question when it comes to more complex pack expansions, but I don’t find it too unnatural to read, e.g.:
return List(elements: Optional(elements)...)
In my mental model, when elements is expanded into a comma-separated list of, well, elements, each element takes along its own copy of the surrounding structure in which it sits. So Optional(elements), when treated with the expansion operator, naturally becomes Optional(elements.1), Optional(elements.2), and so on.
As I mentioned, another spelling that feels natural on first thinking of it would be element*, so we would have
return List(elements: Optional(element*)...)
This has a bit of the best of both worlds, in that the word itself is singular as is each element type, while the asterisk marks it as different from a normal value name with a particular connotation of plurality. That said, I imagine such a spelling might raise other issues including source compatibility and maybe it does not stand up to serious scrutiny.
FWIW, in my mental model, that's what the pack expansion operator ... does. It isn't element that's plural, it's Optional(element). Under substitution, the name element is replaced with an individual element from the pack.
Another FWIW, I didn't really internalize any of this until I wrote out some code examples and experimented with both naming conventions, so I encourage you to do the same and see how that evolves your understanding! That's not to say that you'll think about the code in the same way that I do - everyone internalizes concepts differently. In any case, I think it's a helpful exercise for folks participating in this discussion 
Thank you for writing this. I found myself nodding along when reading it, as you’ve covered the (large!) space of features and capabilities that I’d hope for variadic generics, and it fits together well.
The area I’m least convinced of is the use of “.element” for getting a pack from a tuple. It's an interesting operation, because it takes a single value and then expands it out into a pack.
For one thing, I think it would help if you tied this bit together explicitly with concrete packs and extensions on tuple types, because it would feel less magical if it had a signature we could write in the language:
extension <Element...> (Element...) {
var element: Element... { /* it's okay for this implementation to be magic */ }
}
That might also make the behavior of .element on a tuple that contains an element labeled "element" clearer, because we'll need some name-lookup rule deals with extensions on labeled tuple types in the general case.
Also, I was a little surprised that this section doesn't contain an example of forwarding, because I think that's really the big win from getting a pack from a tuple:
struct CapturedArguments<Result, Parameters...> {
var arguments: (Parameters...)
func evaluate(with function: (Parameters...) -> Result) -> Result {
return function(arguments.element...)
}
}
Forwarding is mentioned earlier, but only in the "this is why packs and tuples are different" section as a reason for making them different.
Now, the moment I see forwarding, scope creep sets in and I would like to also solve the variadic forwarding problem. Can I have .element on an array, for example?
func f(_ args: Int...) { }
func g(_ args: Int...) {
f(args.element...) // could this make sense?
}
It's in a sense very different, because the length of the array is a run-time value, so you have a concrete type [Int] that would need to be expanded into a homogeneous parameter pack of runtime-computed length. But I think we can express that notion of a "homogeneous parameter pack of runtime-computed length" already through the generics system:
func gPrime<T...>(_ args: T...) where T == Int {
f(args.element...) // okay, I think? expand the homogeneous pack and capture results into array
}
Allowing an array (or any Sequence?) to be turned into a homogeneous parameter pack has a similar feel to implicit opening of existentials, because it takes a run-time-computed value (length for arrays vs. dynamic type for existentials) and turns it into something more static (# of arguments in a pack vs. generic argument of the dynamic type of the existential). For example:
func printAll<T...>(_ args: T...) { }
func printArray<Element>(_ array: [Element])
printAll(array.element...) // # of parameters in the pack "T" depends on length of array!
}
Doug
I can imagine a spelling for this that doesn't require a magic member on tuples, since it is notionally a destructuring binding like we already support on tuples, just variadic:
let (argument...) = arguments // bind elements of tuple `arguments` to value pack `argument`
for arg in argument... { ... } // iterate over pack
function(argument...) // forward pack
It would be nice if there was a way to perform this operation without introducing a temporary binding just for this purpose though.
We've gone back and forth a couple of times on whether a stored property ought to be able to have a pack expansion type T..., rather than a tuple type (T...). Currently we're thinking that this should be allowed.
If stored properties are limited to scalar types, like (T...), then the temporary binding becomes more of a hassle because basically doing anything with a (T...) requires expanding it into a pack first. Perhaps by allowing T... stored properties, we eliminate most of the pain and expansion becomes a less-frequent operation.
It would also be nice for computed properties to be able to yield a pack of values by read or modify in-place without having to move them into a tuple first too.
From Destructuring operation using static shape:
Could
let (first, rest...) = (element...)
be used instead? In a failable pattern such as in a case let, there could be no prior knowledge about the underlying shape of a pack and (first, rest) would actually mean "the pack on the right has two scalar elements". I'd prefer to have the same syntax in failable and non failable assignments.
From Exploring syntax alternatives:
Postfix partial range operator is the only one unrelated to the rest. How unfeasible would be to progressively change the range operator from ... to .. in a major Swift version (allow both overloads in Swift 5, warn on Swift 6, ...)?
Would that be enough to remove the .element ceremony for tuples?
Hopefully, just a matter of placing three dots in the right position? 
struct Iterator: IteratorProtocol {
var iterator: Seq.Iterator...
mutating func next() -> (Seq.Element...)? {
guard let element = iterator.next()... else { return nil }
return (element...)
}
}
I imagine that runtime pattern matching / pack destructuring would be done using type coercions with as, because that's the syntax we already have, and because there's probably more than the pack-ness that you want to match against. For example:
switch (element...) {
case let (first, rest) as (First, Rest...):
// do something with 'first' and 'rest'
default:
break
}
This also may be a use case for generalized opaque types for local variables to introduce new generic parameters that can be used for pattern matching.
In my opinion, whether or not value packs are declared with ... after the variable name is orthogonal to the pattern matching syntax; if we decide to use let value... for value packs, we should do it everywhere, including parameter declarations:
func tuplify<T...>(_ t...: T...) { (t...) }
Personally, I find the ... after t to be redundant, and it makes it a little more difficult to think about t: T as the element that is repeated by the ..., but of course that's just the way I think about the code.
Unfortunately it's not just about the postfix range operator .... The partial range operator intentionally uses the same operator as the regular closed range infix operator 1 ... x.count. Then there's also the closely related half-open range operator 1 ..< x.count that intentionally matches the structure of the closed-range operator, just with a different final character to denote the open/closed property of the range. While it might be feasible to change all of these operators to be spelled differently, these are such widely used operators that I don't think it would be worth the tradeoff.
If we're concerned about the existing uses of ... in Swift, I think we should instead consider using a different syntax for variadic generics. I'll admit the * alternative is growing on me. In any case, I'm going to start a dedicated thread to bikeshed the ... syntax for variadic generics so we can figure it out!
No, the operation to access tuple elements as a pack is fundamentally necessary in this design, because otherwise, there would be no way to expand a tuple element-wise in the pattern of a pack expansion. We could choose to instead provide a way to expand a tuple into a local variable pack, and in fact the original draft of this vision document included a "value expansion operation" instead of a direct operation to access tuple elements as a pack, but generalizing tuple types became super annoying because let element = tuple... was the first line of every function that accepted an abstract tuple.
The section of the document comparing tuples and packs explains this in more detail, and provides a few examples of the difference between using a tuple in the pattern of a pack expansion vs using the tuple elements as a pack.
Neat! I didn't think about this, but I agree that guard let and friends should be supported with local variable packs.