I think the generic typealiases Doug mentioned are a pretty good approximation of a type parameter on a protocol. After all, you should be able to do this:
typealias AnyCollection<T> = Any<Collection where .Element == T> Speaking of which, I went ahead and rewrote the proposal based on Doug's feedback. I look forward to discussing it in depth later this year/early next year. (Suggestions for a better example than the ridiculous pet hotel example at the beginning especially welcome...) https://github.com/austinzheng/swift-evolution/blob/az-existentials/proposals/XXXX-enhanced-existentials.md <https://github.com/austinzheng/swift-evolution/blob/az-existentials/proposals/XXXX-enhanced-existentials.md> Austin > On Jun 8, 2016, at 11:57 AM, Dave Abrahams via swift-evolution > <[email protected]> wrote: > >>> >>> FWIW, we also occasionally get "Swift should have parameterized >>> protocols" in the context of multiple conformances by the same >>> concrete type (as in things like ConvertibleTo<T> protocol). >> >> I know. From the bugs I've seen it's at least 10x as many requests for >> "any collection of some element type" as for any actually reason why >> one would need parameterize a protocols. > > That does, however, speak for the idea that a concise and obvious syntax > should be supported for that use-case. > > Personally, it doesn't seem ridiculous to me that some associated types > might usefully be written as type parameters on a protocol. As > Collection shows, not all associated types are equally important. > Approximately nobody wants the existential “Collection where Index == > Int.” > > -- > Dave > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
