[swift-evolution] Enhanced existential types proposal discussion

[Matthew Johnson]

Sent from my iPad

> On May 22, 2016, at 5:18 PM, Austin Zheng via swift-evolution <swift-evolution at swift.org> wrote:
> 
> I agree; the difference between protocols with and without associated types has been an endless source of confusion for a lot of people.
> 
> Speaking of which, for those who care I rewrote the draft proposal to attempt a much more rigorous treatment of the semantics of the generalized existential, including a discussion about existential type equivalence and subtyping. It would be nice to see people poke holes in my logic so I can patch them up. https://github.com/austinzheng/swift-evolution/blob/az-existentials/proposals/XXXX-enhanced-existentials.md

This looks really nice.  I really, really appreciate all of your hard work on this.  It addresses one of the very largest pain points in Swift and does so comprehensively.  (The other really large pain point IMO is lack of conditional conformance).

I haven't had time to thoroughly review every detail but didn't see errors in a relatively quick glance over it.

> 
> Austin
> 
>>> On May 22, 2016, at 3:05 PM, Russ Bishop via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>>> 
>>> On May 17, 2016, at 1:55 PM, Joe Groff via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>>> I agree with this. If we're certain we should reskin protocol<> as Any<>, we should frontload that change—in addition to affecting source code, it'd also influence the runtime behavior of type printing/parsing, which can't be statically migrated in the future. I think any discussion of extending existentials has to be considered out of scope for Swift 3, though, so the Any rename deserves its own proposal.
>>> 
>>> -Joe
>> 
>> 
>> Its really unfortunate that the generics work is probably going to be deferred. When you really dive in to protocol-oriented programming and designing frameworks to be native Swift (taking advantage of Swift features) the existential problem comes up a lot and leads to sub-optimal designs, abandonment of type safety, or gobs of boilerplate.  
>> 
>> 
>> Russ
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> 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/20160523/7d748a9d/attachment.html>