> Am 23.05.2016 um 00:18 schrieb Austin Zheng via swift-evolution > <[email protected]>: > > 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
I think that *all* methods should be available - at least in principle - with associated types - replaced by their upper bounds (i.e. Any if no constraints have been given either by the protocol definition itself or th existential) if in covariant position and - replaced by their lower bounds if in contravariant position As it is not possible to define lower bounds in Swift, the lower bounds are always the bottom type (called `Nothing` in Swift and not be confused with optionals). The bottom type has no members and therefore a method referencing that type cannot be called and is effectively not available. -Thorsten > > 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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
