I'm very against this. As @regexident says, this syntax is important for a major missing Swift feature, generic protocols.
This feature is used extensively in Rust, where it forms the backbone of generic conversion and operator overloading, and is one of the things I miss most when moving between the languages. I understand that the implementation in Swift is difficult and the idea has been passed over before for various reasons, but I remain convinced that this is an eventual necessity for Swift.
the obvious interpretation of this syntax is as a generic protocol, so this usage of this syntax will inherently be misleading. You can't actually use it how it looks:
extension Data: Collection<UInt8> { ... }
extension Data: Collection<UInt32> { ... }
is still an error due to overlapping conformances.
Likewise, you can't make any number of overlapping conformances:
protocol RawBytes { ... }
extension Data: Collection<T> where T: RawBytes { ... }
But also, it's lying about fundamental truths of Swift syntax. For better or worse, <T> means T is an input type, under the control of the programmer at that moment. With this proposal, <T> has an alternate meaning as a constraint of some invisible associated type to be equal to T.
I agree again with @regexident that an appropriate syntax for this is <.AssociatedType == T>, which
- more or less matches Rust's syntax for the same purpose
- is explicit about exactly which associated types are being constrained
- doesn't require adding the concept of a "primary" associated type to the language
- is flexible with regard to adding many constraints of many associated types (just use commas to separate the constraints)
- is orthogonal to existing syntax rather than confusingly overlapping
- allows us to keep the possibility of generic protocols open for the future (we're gonna want 'em)