<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 8:51 AM, Jan E. Schotsman 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="">On May 26, 2016, at 3:44 PM, Austin Zheng wrote:<br class=""><br class=""><blockquote type="cite" class="">The inimitable Joe Groff provided me with an outline as to how the design<br class="">could be improved. I've taken the liberty of rewriting parts of the<br class="">proposal to account for his advice.<br class=""></blockquote><br class="">Looks like great progress!<br class=""><br class="">A few remarks:<br class=""><br class="">1.I don't see the need for AllOf. A nested existential also acts as a constraint bundle, so you would have to write<br class=""><br class="">Any<ProtocolA, AllOf< ProtocolB, ProtocolC>><br class=""><br class="">for consistency.<br class=""></div></div></blockquote><div><br class=""></div><div>I’ve been thinking about this as well, especially in the context of Brent’s idea to distinguish existentials from generic constraints. My conclusion is that disallowing use of `Any` (or typealiases of `Any`) in generic constraints is an arbitrary restriction and introducing a new name `AllOf` for something that is structurally the same is unnecessary and potentially confusing.</div><div><br class=""></div><div>I would like to see us eventually introduce a first class mechanism for abstracting constraints. That mechanism would become the preferred mechanism for factoring constraints, used in both generics and existentials. When we have that mechanism it might be reasonable to push people to use it rather than “existential constraints”. Maybe this can even happen along side enhanced existentials in Swift 4.</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class="">In a "is subclass of" constraint the superclass also acts as a constraint bundle, in a sense.<br class=""><br class=""></div></div></blockquote><blockquote type="cite" class=""><div class=""><div class="">2.If openas never fails why do we need to use optional binding with it?<br class=""></div></div></blockquote><div><br class=""></div><div>I assume you’re talking about this:</div><div><br class=""></div><div><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; color: rgb(51, 51, 51);" class=""><span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">let</span> e1: <span class="pl-c1" style="box-sizing: border-box; color: rgb(0, 134, 179);">Equatable</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);">...</span>
<span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">let</span> e2: <span class="pl-c1" style="box-sizing: border-box; color: rgb(0, 134, 179);">Equatable</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);">...</span>
<span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">if</span> <span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">let</span> storedInE1 <span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">=</span> e1 openas T {
<span class="pl-c" style="box-sizing: border-box; color: rgb(150, 152, 150);">// is e2 also a T? </span>
<span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">if</span> <span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">let</span> storedInE2 <span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">=</span> e2 <span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">as?</span> T {
<span class="pl-c" style="box-sizing: border-box; color: rgb(150, 152, 150);">// okay: storedInT1 and storedInE2 are both of type T, which we know is Equatable</span>
<span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">if</span> storedInE1 <span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">==</span> storedInE2 { <span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">...</span> }
}
}</pre><div class=""><br class=""></div><div class="">That is a good question. I imagine the purpose is to require a new scope to be introduced, inside which `T` is bound to the dynamic type of `e1` and `storedInE1` is bound to a value of that type. I am not sure why we need a new scope for these bindings rather than allowing them to be in effect in the surrounding scope (this may have been discussed already). If the new scope is necessary it might be worth elaborating on why. Otherwise, it would be simper if we could just do this:</div><div class=""><br class=""></div><div class=""><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; color: rgb(51, 51, 51);" class=""><span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">let</span> e1: <span class="pl-c1" style="box-sizing: border-box; color: rgb(0, 134, 179);">Equatable</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);">...</span>
<span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">let</span> e2: <span class="pl-c1" style="box-sizing: border-box; color: rgb(0, 134, 179);">Equatable</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);">...</span>
<span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">let</span> storedInE1 <span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">=</span> e1 openas T
<span class="pl-c" style="box-sizing: border-box; color: rgb(150, 152, 150);">// is e2 also a T? </span>
<span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">if</span> <span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">let</span> storedInE2 <span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">=</span> e2 <span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">as?</span> T {
<span class="pl-c" style="box-sizing: border-box; color: rgb(150, 152, 150);">// okay: storedInT1 and storedInE2 are both of type T, which we know is Equatable</span>
<span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">if</span> storedInE1 <span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">==</span> storedInE2 { <span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">...</span> }
}</pre><div class=""><br class=""></div></div></div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class="">3. You have a typo in the "where clause" section: where Collection.Element == Streamable<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="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></div></blockquote></div><br class=""></body></html>