Sent from my iPad

> On May 22, 2016, at 5:18 PM, Austin Zheng via swift-evolution 
> <swift-evolution@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@swift.org> wrote:
>>> 
>>> 
>>> On May 17, 2016, at 1:55 PM, Joe Groff via swift-evolution 
>>> <swift-evolution@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@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to