[swift-evolution] Enhanced existential types proposal discussion

[Austin Zheng]

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 <swift-evolution at swift.org> 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
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160608/e4fcb1e0/attachment.html>