<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=""><div class="">added a few comments to <a href="https://gist.github.com/lmihalkovic/68c321ea7ffe27e553e37b794309b051" class="">https://gist.github.com/lmihalkovic/68c321ea7ffe27e553e37b794309b051</a> to clarify the rational. it is by no mean the only way or a good way, but IMO there are far worse ways to do the same.</div><div class=""><br class=""></div><div class=""><br class=""></div><div><blockquote type="cite" class=""><div class="">On Jun 6, 2016, at 1:20 AM, Douglas Gregor 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=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On May 18, 2016, at 12:35 AM, Austin Zheng <<a href="mailto:austinzheng@gmail.com" class="">austinzheng@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">I've put together a considerably more detailed draft proposal, taking into account as much of Matthew's feedback as I could. You can find it below:<div class=""><br class=""></div><div class=""><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><br class=""></div><div class=""><br class=""></div><div class="">Since there is no chance this will come up for review anytime soon, I expect to make significant revisions to it over the next month or so. Any feedback would be greatly appreciated.</div></div></div></blockquote><div class=""><br class=""></div><div class="">This is very much Swift 4 territory, but I can’t help myself… so…</div><div class=""><br class=""></div><div class="">The actual feature description is spread out through this very long document, with user-facing ideas (e.g., using “anonymous associated types”) intermixed with deeper technical details (existential type equivalence), so it’s very daunting to read. Please bring the user-facing features to the front (“Proposed Solution”) with examples, and save the deeper technical details for “Detailed Design”. You want more readers to make it through the part that affects them.</div><div class=""><br class=""></div><div class=""><p style="box-sizing: border-box; margin-top: 0px; margin-bottom: 16px; color: rgb(51, 51, 51); font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; background-color: rgb(255, 255, 255);" class=""><span style="box-sizing: border-box;" class="">Shortcut 'dot' notation</span>: If there is only one protocol with associated types specified in the requirements, and there are no nested <code style="box-sizing: border-box; font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; font-size: 14px; padding: 0.2em 0px; margin: 0px; background-color: rgba(0, 0, 0, 0.0392157); border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px;" class="">Any<...></code> requirements with <code style="box-sizing: border-box; font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; font-size: 14px; padding: 0.2em 0px; margin: 0px; background-color: rgba(0, 0, 0, 0.0392157); border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px;" class="">where</code> clauses of their own, that protocol's name can be omitted from the <code style="box-sizing: border-box; font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; font-size: 14px; padding: 0.2em 0px; margin: 0px; background-color: rgba(0, 0, 0, 0.0392157); border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px;" class="">where</code>clause constraints:</p><div class="highlight highlight-source-swift" style="box-sizing: border-box; margin-bottom: 16px; color: rgb(51, 51, 51); font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; background-color: rgb(255, 255, 255);"><pre style="box-sizing: border-box; font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; font-size: 14px; margin-top: 0px; margin-bottom: 0px; line-height: 1.45; word-wrap: normal; padding: 16px; overflow: auto; background-color: rgb(247, 247, 247); border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px; word-break: normal;" class=""><span class="pl-c" style="box-sizing: border-box; color: rgb(150, 152, 150);">// Okay</span>
<span class="pl-c" style="box-sizing: border-box; color: rgb(150, 152, 150);">// Would otherwise be Any< ~ where Collection.Element == Int></span>
<span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">let</span> a <span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">:</span> <span class="pl-c1" style="box-sizing: border-box; color: rgb(0, 134, 179);">Any</span><span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);"><</span><span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">class</span>, Collection, <span class="pl-c1" style="box-sizing: border-box; color: rgb(0, 134, 179);">Any</span><span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);"><</span><span class="pl-c1" style="box-sizing: border-box; color: rgb(0, 134, 179);">Streamable</span>, <span class="pl-c1" style="box-sizing: border-box; color: rgb(0, 134, 179);">CustomStringConvertible</span><span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">></span> <span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">where</span> <span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">.</span>Element <span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">==</span> <span class="pl-c1" style="box-sizing: border-box; color: rgb(0, 134, 179);">Int</span><span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">></span>
<span class="pl-c" style="box-sizing: border-box; color: rgb(150, 152, 150);">// NOT ALLOWED</span>
<span class="pl-c" style="box-sizing: border-box; color: rgb(150, 152, 150);">// Both Collection and OptionSetType have associated types.</span>
<span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">let</span> b <span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">:</span> <span class="pl-c1" style="box-sizing: border-box; color: rgb(0, 134, 179);">Any</span><span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);"><</span>Collection, <span class="pl-c1" style="box-sizing: border-box; color: rgb(0, 134, 179);">OptionSetType</span> <span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">where</span> <span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">.</span>Element <span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">==</span> <span class="pl-c1" style="box-sizing: border-box; color: rgb(0, 134, 179);">Int</span><span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">></span></pre></div><div class="">FWIW, I think “.Element == Int” should be the only syntax. In generic signatures, if you have two different protocols with same-named associated types, and a given type parameter (or associated type) conforms to both protocols, the associated types are (implicitly) made equivalent via an inferred same-type constraint. So there’s no reason to introduce the “Collection.Element == Int” syntax, because the “Collection” part is basically irrelevant.</div><div class=""><br class=""></div></div><div class="">Once existentials have been suitably enhanced, there is a strong analogy between an existential and a generic signature with a single type parameter that you can’t name. An existential Any<Collection where .Element : Equatable> has most of the same characteristics as a generic something with the signature <T : Collection where T.Element : Equatable>. Specifically, the sections on “Existential type equivalence”, “Ordering”, “Real types to anonymous associated types”, “Anonymous associated types to real types”. could be reduced to a few small, simple examples and a mention of the analogous behavior of generics. It will be far easier to explain this way, and readers don’t need to get immersed in the details. Where there are differences vs. generics, that’s important to point out.</div><div class=""><br class=""></div><div class="">“Associated typealias rewriting”: this also falls out of the equivalence with generics + SE-0092.</div><div class=""><br class=""></div><div class="">“Associated types and member exposure”: you don’t make the point that it only makes sense to refer to the associated types of a <b class="">let</b> constant; a <b class="">var</b> could change its type dynamically, which would invalidate the typing rules. Did you consider just using “x.dynamicType” in the type grammar for this? It’s more general, in that you can refer to associated types but also talk about the dynamic type of “x” itself, e.g.,</div><div class=""><br class=""></div><div class=""><font face="Menlo" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>let x: Equatable = …</font></div><div class=""><font face="Menlo" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>let y: Equatable = …</font></div><div class=""><font face="Menlo" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>if let yAsX = y as? x.dynamicType { … x == yAsX … }</font></div><div class=""><br class=""></div><div class="">which is (almost?) as powerful as a general “open” expression.</div><div class=""><br class=""></div><div class="">I’m not a fan of the “anonymous associated types” terminology: these are associated types of a type of some runtime-defined value. The only thing “anonymous” about them is that it’s harder to spell the base type; otherwise, they’re just like associated types of a generic type parameter. Again, the generics analogy is strong here.</div><div class=""><br class=""></div><div class="">FWIW, I don’t think we’ll ever need “opening existentials” with what you’ve described here. Also, remember that a method of a protocol extension essentially opens “Self”, so we already have one way to open an existential (and that’s probably enough).</div><div class=""><br class=""></div><div class="">I was a little surprised you didn’t point out that AnyObject could become</div><div class=""><br class=""></div><div class=""><font face="Menlo" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>typealias AnyObject = Any<class></font></div><div class=""><br class=""></div><div class="">or give the nice “AnyCollection” syntax:</div><div class=""><br class=""></div><div class=""><font face="Menlo" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>typealias AnyCollection<T> = Any<Collection where .Element == T></font></div><div class=""><br class=""></div><div class="">the latter of which is fairly important, because it gives nice syntactic sure to one of the most highly-requested features [*]. I’d suggest having that example very, very early.</div><div class=""><br class=""></div><span class="Apple-tab-span" style="white-space:pre"> </span>- Doug</div><div class=""><br class=""></div><div class="">[*] That generally comes in as “Swift should have parameterized protocols…”</div><div class=""><br class=""></div></div></div></blockquote><br class=""></div><div><br class=""></div><div>@doug : watched and very much appreciated your presentation on what makes a good API… reminded me of a job interview with Bertand Serlet a few years ago.. you guys have managed to remain very consistent over a very long period of time, and it looks like Swift is following in the foot-steps. </div><div> </div><div><br class=""></div></body></html>