<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">Am 23.05.2016 um 19:17 schrieb Matthew Johnson <<a href="mailto:matthew@anandabits.com" class="">matthew@anandabits.com</a>>:</div><br class="Apple-interchange-newline"><div class=""><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div class=""><br class="Apple-interchange-newline">On May 23, 2016, at 10:57 AM, Thorsten Seitz via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="auto" class=""><div class=""></div><div class=""><br class=""></div><div class=""><br class="">Am 23.05.2016 um 00:18 schrieb Austin Zheng via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>>:<br class=""><br class=""></div><blockquote type="cite" class=""><div class="">I agree; the difference between protocols with and without associated types has been an endless source of confusion for a lot of people.<div class=""><br class=""></div><div class="">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. <a href="https://github.com/austinzheng/swift-evolution/blob/az-existentials/proposals/XXXX-enhanced-existentials.md" class="">https://github.com/austinzheng/swift-evolution/blob/az-existentials/proposals/XXXX-enhanced-existentials.md</a></div></div></blockquote><div class=""><br class=""></div>I think that *all* methods should be available - at least in principle - with associated types <div class="">- 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 </div><div class="">- replaced by their lower bounds if in contravariant position</div><div class=""><br class=""></div><div class="">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.</div></div></div></blockquote><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">Called `Nothing` in Swift? Where do you get that? `func foo(s: Nothing) {}` gives me “use of undeclared type `Nothing`”. If Swift had a bottom type wouldn’t we be able to declare a function accepting an argument of type `Nothing` (we could just never call it because we couldn’t construct an argument).</div></div></blockquote><div><br class=""></div>oops, sorry, I had wanted to type „called `Nothing` in Scala“ :-)</div><div><br class=""></div><div>-Thorsten</div><div><br class=""></div><div><br class=""><blockquote type="cite" class=""><div class=""><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div class=""><div dir="auto" class=""><div class=""><br class=""></div><div class="">-Thorsten </div><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class=""></div><div class="">Austin<br class=""><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On May 22, 2016, at 3:05 PM, Russ Bishop via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><br class=""><blockquote type="cite" class="">On May 17, 2016, at 1:55 PM, Joe Groff via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class="">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.<br class=""><br class="">-Joe<br class=""></blockquote><br class=""><br class="">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. <br class=""><br class=""><br class="">Russ<br class=""><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></div></blockquote></div><br class=""></div></div></div></blockquote><blockquote type="cite" class=""><div class=""><span class="">_______________________________________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></div></blockquote></div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></div></blockquote></div></blockquote></div><br class=""></body></html>