I'm excited for this work, and agree with many of the points made here about legibility. This is an advanced feature and we should consider less experienced developers encountering it for the first time. "Swift generic type postfix star" seems like an ineffective search term and I'd wager folks can come up with a bunch of equally SEO-unfriendly variations on this for each of the symbol-based approaches suggested here. Using a keyword seems much better in this regard, something like "Swift many expanded keywords" seems more likely to yield good results. Super +1 if we can come up with keywords that can be broadly understood without searching.
Also, because this is an advanced feature, I see little downside to erring on the side of verbosity. This is especially true when you consider the syntax it is replacing is 10 overloads of the same method with N type parameters each.
This may be a bit out-of-scope as this proposal explicitly excludes associated types, but I think the design would benefit from discussing how this would affect a potential implementation of static structural reflection. Something like:
protocol Structural {
static var storedProperties: many StoredProperty<Self, _> { get }
}
allowing the user to define (using @Jumhyn's notation):
protocol OnlyIntProperties: Structural where forEach(T in storedProperties, T.Value == Int) {
}
It would be great if at least this specific use case could leverage semantics similar to whatever we decide on here (for the record, I'm not suggesting we implement this as part of this proposal, just that the semantics are extensible enough to support it).