<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 &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; 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&lt;ProtocolA, AllOf&lt; ProtocolB, ProtocolC&gt;&gt;<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. &nbsp;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. &nbsp;That mechanism would become the preferred mechanism for factoring constraints, used in both generics and existentials. &nbsp;When we have that mechanism it might be reasonable to push people to use it rather than “existential constraints”. &nbsp;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. &nbsp;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. &nbsp;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). &nbsp;If the new scope is necessary it might be worth elaborating on why. &nbsp;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: &nbsp;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>