<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="">On May 26, 2016, at 6:08 AM, Matthew Johnson <<a href="mailto:matthew@anandabits.com" class="">matthew@anandabits.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=""><br class=""><br class="">Sent from my iPad</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="">On May 26, 2016, at 6:59 AM, Taras Zakharko via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" 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=""><div class="">This looks very nice!<div class=""><br class=""></div><div class="">Two questions/comments</div><div class=""><br class=""></div><div class="">1. I would prefer to write simpler existential types without Any, e.g.:</div><div class=""><br class=""></div><div class=""> let a: Sequence where Sequence.Iterator.Element == Int</div><div class=""><br class=""></div><div class=""> Is there a reason why we need Any<> at all, aside as a parsing aid?</div><div class=""><br class=""></div><div class="">2. If this proposal gets accepted, does it mean that type-erased wrappers like AnySequence become superfluous? They always struck me as a hack, used only to overcome the limitations of the type system. </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><span 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;" class="">Many type-erase wrappers will be unnecessary. However, if you look at AnyCollection it defines AnyIndex. You can pass values of this type that come from one value of AnyCollection to another AnyCollection even if it has a totally different underlying type. In other words, it is explicitly type unsafe and will call fatalError if you use a bad index. </span></div></blockquote><div><br class=""></div><div>I think this actually shouldn't be a problem anymore (warning, strawman syntax):</div><div><br class=""></div><div>func doSomethingWithTwoCollections(x: Any<Collection>, y: Any<Collection>) {</div><div> </div><div> let anIndex : x.Index = x.startIndex</div><div> var anotherIndex : y.Index = y.startIndex</div><div> </div><div> // NOT ALLOWED - x.Index and y.Index are not equivalent</div><div> anotherIndex = anIndex</div><div><br class=""></div><div> // With the new collection model (SE-0065), indices are simply Comparable now</div><div> // Okay to cast from x.Index to Comparable</div><div> let a = anIndex as Comparable</div><div><br class=""></div><div> // Not okay to cast from Comparable to y.Index</div><div> let b = a as y.Index</div><div><br class=""></div><div> // This should be okay. We may want to break this feature into 'Opening Existentials' follow-up proposal</div><div> if let b = a as? y.Index {</div><div> // do stuff with b</div><div> }</div><div>}</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><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=""><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="">If you want behavior like that you will still have to implement it manually. But it's probably more an artifact of the state of the language at the time AnyCollection was designed than anything else. I think we'd prefer safe behavior, which is possible with the latest update to this proposal (exposing associated types as 'anonymous types' where safe use with the existential that produced them is well defined) .<div class=""><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class=""></div><div class="">Best, </div><div class=""><br class=""></div><div class=""> Taras</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 26 May 2016, at 07:53, Austin Zheng 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="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></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></div></blockquote></div></div></div></blockquote></div><br class=""></body></html>