Highly positive! This is a natural follow-on to the parameter packs proposal, and (to me) a necessary part of variadic generics. I'm glad to see it up for review.
I have a few comments on narrow issues, but nothing that should prevent this proposal from being accepted.
In the requirements section, there is this restriction that I don't understand:
i. The inferred requirement is invalid if it contains multiple pack elements captured by expansions at different depths.
I thought that it would be acceptable to have a shape constraint that equates the shapes of packs at different depths, so why would the inferred requirement need to be invalid?
In the section on typealiases, the generic parameter packs are missing. This:
typealias Element = (repeat each S.Element)
typealias Callback = (repeat each S) -> ()
typealias Factory = Other<repeat each S>
should probably be
typealias Element<each S: Sequence> = (repeat each S.Element)
typealias Callback<each S> = (repeat each S) -> ()
typealias Factory<each S> = Other<repeat each S>
The section on classes has this restriction:
While there are no restrictions on non-final classes adopting type parameter packs, for the time being the proposal restricts such classes from being the superclass of another class.
This has the feel of being a limitation on the current implementation (i.e., nobody has implemented this bit yet) vs. a fundamental design issue that needs to be sorted out. Are there unknowns here that could mean that we have this restriction forever, or would somehow be unable to handle inheritance? If not, I'd rather not have the restriction in the proposal itself, and leave it to a compiler release note.
Doug