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 <https://github.com/austinzheng/swift-evolution/blob/az-existentials/proposals/XXXX-enhanced-existentials.md> Austin > On May 22, 2016, at 3:05 PM, Russ Bishop via swift-evolution > <[email protected]> wrote: > > >> On May 17, 2016, at 1:55 PM, Joe Groff via swift-evolution >> <[email protected]> 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
