<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div>Great! Thanks!</div><div><br></div><div>-Thorsten </div><div><br>Am 29.05.2016 um 22:29 schrieb Austin Zheng <<a href="mailto:austinzheng@gmail.com">austinzheng@gmail.com</a>>:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8">I'll add it to the "Future Directions" section. I feel that's the best place to put it, since there's no guarantee that Swift will get a bottom type, and because making existentials to work with a bottom type would be a completely additive change.<div class=""><br class=""><div class="">Austin<br class=""><div class=""><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On May 29, 2016, at 12:48 PM, Thorsten Seitz <<a href="mailto:tseitz42@icloud.com" class="">tseitz42@icloud.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><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=""><blockquote type="cite" class=""><div class=""><br class="Apple-interchange-newline">Am 29.05.2016 um 18:07 schrieb Austin Zheng <<a href="mailto:austinzheng@gmail.com" class="">austinzheng@gmail.com</a>>:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br class=""><div class=""><blockquote type="cite" class=""><div class="">On May 29, 2016, at 7:04 AM, Matthew Johnson <<a href="mailto:matthew@anandabits.com" class="">matthew@anandabits.com</a>> wrote:</div><div class=""><br class=""><div 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;"><br class=""></div><span 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; float: none; display: inline !important;">This makes a lot more sense! So you want to be able to use uninhabitable types in the contexts of things like collection elements (such collections must always be empty but are inhabitable by a single empty instance). It is a great example of why it might make sense to allow types like this. </span><div 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;"><br class=""></div><div 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;">What you are really asking for is the ability to drop the restriction that only a single superclass constraint is allowed and no value type constraints are allowed. It might be useful in cases like your intersection example. But it could also be a source of error confusing error messages when people form such a type and it doesn't work the way they expect. If the type is disallowed as under the current proposal the error message might be more straightforward. This is a topic that probably deserves further consideration. But I have to say I find your intersection example to be reasonably compelling.</div><div 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;"><br class=""></div><div 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;">Austin, what do you think about this example?<br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">I personally don't feel like the additional complexity is worth it as Swift exists today.</div></div></div></div></blockquote><div class=""><br class=""></div>I agree that adding a bottom type would be a different proposal. As an intermediate step we could just make it a type error if an existential would only be satisfied by the bottom type. </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=""><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="">-Thorsten</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=""><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=""><br class=""><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><div class=""><br class=""></div><div class="">Swift getting a real bottom type would be a completely different proposal. It would allow you to do things like:</div><div class=""><br class=""></div><div class="">let universalNil : Bottom? = nil</div><div class="">var a : Int? = universalNil</div><div class="">var b : UIView? = universalNil</div><div class=""><br class=""></div><div class="">and so on.</div><div class=""><br class=""></div><div class="">If Swift does ever get such a type relaxing the restriction from the proposal would be an additive change, and could be proposed separately as a follow up addition.</div></div></div></div></blockquote><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><div class=""><br class=""></div><div class="">Austin</div><div class=""><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div 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=""><blockquote type="cite" class=""><div class=""><div class=""><br class=""></div><div class="">-Thorsten</div><div class=""><br class=""></div><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><br class=""></div><div class="">To write this `union` and have it behave in the usual way you need `Any<A, B>` to be a supertype of `A` and of `B`. The existential doesn’t actually do that so it would not be possible for this union function to guarantee the result would have all of the members of `x` and all the members of `y` the way that a `union` usually would. </div><div class=""><br class=""></div><div class="">The anonymous union type `A | B` *is* a supertype of `A` and a supertype of `B` so you would have no trouble writing this:</div><div class=""><br class=""></div><div class="">func union<A, B>(x: Set<A>, y: Set<B>) -> Set<A | B> { … }</div><div class=""><br class=""></div><div class="">And returning the expected result.</div><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><br class=""></div><div class=""><br class=""></div><div class="">-Thorsten</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class="">Am 26.05.2016 um 07:53 schrieb Austin Zheng via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>>:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">The inimitable Joe Groff provided me with an outline as to how the design could be improved. I've taken the liberty of rewriting parts of the proposal to account for his advice.<div class=""><br class=""></div><div class="">It turns out the runtime type system is considerably more powerful than I expected. The previous concept in which protocols with associated types' APIs were vended out selectively and using existentials has been discarded.</div><div class=""><br class=""></div><div class="">Instead, all the associated types that belong to an existential are accessible as 'anonymous' types within the scope of the existential. These anonymous types are not existentials - they are an anonymous representation of whatever concrete type is satisfying the existential's value's underlying type's associated type.</div><div class=""><br class=""></div><div class="">This is an enormous step up in power - for example, an existential can return a value of one of these anonymous associated types from one function and pass it into another function that takes the same type, maintaining perfect type safety but without ever revealing the actual type. There is no need anymore to limit the APIs exposed to the user, although there may still exist APIs that are semantically useless without additional type information.</div><div class=""><br class=""></div><div class="">A set of conversions has also been defined. At compile-time 'as' can be used to turn values of these anonymous associated types back into existentials based on the constraints defined earlier. 'as?' can also be used for conditional casting of these anonymously-typed values into potential actual types.</div><div class=""><br class=""></div><div class="">As always, the link is here, and feedback would be greatly appreciated: <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 class=""><br class=""></div><div class="">Best,</div><div class="">Austin</div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Tue, May 24, 2016 at 5:09 AM, Matthew Johnson via swift-evolution<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><br class=""><br class="">Sent from my iPad<br class=""><span class=""><br class="">On May 23, 2016, at 9:52 PM, Brent Royal-Gordon via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class="">>> One initial bit of feedback - I believe if you have existential types, I believe you can define Sequence Element directly, rather than with a type alias. e.g.<br class="">>><br class="">>> protocol Sequence {<br class="">>> associatedtype Element<br class="">>> associatedtype Iterator: any<IteratorProtocol where IteratorProtocol.Element==Element><br class="">>> associatedtype SubSequence: any<Sequence where Sequence.Element == Element><br class="">>> …<br class="">>> }<br class="">><br class="">> That's not really the same thing. Any<IteratorProtocol> is an existential, not a protocol. It's basically an automatically-generated version of our current `AnyIterator<T>` type (though with some additional flexibility). It can't appear on the right side of a `:`, any more than AnyIterator could.<br class=""><br class=""></span>After this proposal you should be able to use these existentials anywhere you can place a constraint, so it would work. You can do this with the protocol composition operator today and the future existential is just an extension of that capability.<br class=""><span class="im HOEnZb"><br class="">><br class="">> What *would* work is allowing `where` clauses on associated types:<br class="">><br class="">>> protocol Sequence {<br class="">>> associatedtype Element<br class="">>> associatedtype Iterator: IteratorProtocol where Iterator.Element==Element<br class="">>> associatedtype SubSequence: Sequence where SubSequence.Element == Element<br class="">>> …<br class="">>> }<br class="">><br class="">> I believe this is part of the generics manifesto.<br class="">><br class="">> --<br class="">> Brent Royal-Gordon<br class="">> Architechies<br class="">><br class=""></span><div class="HOEnZb"><div class="h5">> _______________________________________________<br class="">> swift-evolution mailing list<br class="">><span class="Apple-converted-space"> </span><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">><span class="Apple-converted-space"> </span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><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" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></div></blockquote></div><br class=""></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><br class=""></div></blockquote></div><br class=""></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></div></div></blockquote></div></div></blockquote></div></div></div></blockquote></div></div></div></blockquote></div></div></blockquote></div><br class=""></div></div></div></div></div></blockquote></body></html>