<div dir="ltr">On Sun, Jan 29, 2017 at 2:40 PM, Matthew Johnson <span dir="ltr">&lt;<a href="mailto:matthew@anandabits.com" target="_blank">matthew@anandabits.com</a>&gt;</span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><span class=""><blockquote type="cite"><div>On Jan 29, 2017, at 2:25 PM, Xiaodi Wu &lt;<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>&gt; wrote:</div><br class="m_452239474072986915Apple-interchange-newline"><div><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">On Sun, Jan 29, 2017 at 2:16 PM, Matthew Johnson<span class="m_452239474072986915Apple-converted-space"> </span><span dir="ltr">&lt;<a href="mailto:matthew@anandabits.com" target="_blank">matthew@anandabits.<wbr>com</a>&gt;</span><span class="m_452239474072986915Apple-converted-space"> </span>wrote:<br><div class="gmail_extra"><div class="gmail_quote"><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"><div style="word-wrap:break-word"><br><div><span><blockquote type="cite"><div>On Jan 29, 2017, at 2:01 PM, Xiaodi Wu &lt;<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>&gt; wrote:</div><br class="m_452239474072986915m_3246467056528599417Apple-interchange-newline"><div><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">On Sun, Jan 29, 2017 at 1:37 PM, Matthew Johnson<span class="m_452239474072986915m_3246467056528599417Apple-converted-space"> </span><span dir="ltr">&lt;<a href="mailto:matthew@anandabits.com" target="_blank">matthew@anandabits.co<wbr>m</a>&gt;</span><span class="m_452239474072986915m_3246467056528599417Apple-converted-space"> </span>wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="auto"><div><br><br>Sent from my iPad</div><span class="m_452239474072986915m_3246467056528599417gmail-"><div><br>On Jan 29, 2017, at 12:58 PM, Xiaodi Wu via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br><br></div><blockquote type="cite"><div>Cool. Another avenue of improvement here is relaxing the single-class spelling rule for the sake of composing typealiases.<br><br>As Matthew mentioned, if I have class Base and typealiases Foo = Base &amp; Protocol1 and Bar = Base &amp; Protocol2, it&#39;d be nice to allow Foo &amp; Bar.<br><br>It&#39;d be nice to go one step further: given class Derived : Base, if I have typealiases Foo2 = Base &amp; Protocol1 and Bar2 = Derived &amp; Protocol2, then it could be permitted to write Foo2 &amp; Bar2, since there is effectively only one subclass requirement (Derived).<br><br>As I understand it, the rationale for allowing only one subclass requirement is that Swift supports only single inheritance. Thus, two disparate subclass requirements Base1 &amp; Base2 would make your existential type essentially equivalent to Never. But Base1 &amp; Base1 &amp; Base1 is fine for the type system, the implementation burden (though greater) shouldn&#39;t be too awful, and you would measurably improve composition of typealiases.<br></div></blockquote><div><br></div></span><div>Yes, this is what I was indicating in my post as well.</div><div><br></div><div>Are you suggesting that Base1 &amp; Base2 compose to a type that is treated identically to Never do you think it should be an immediate compiler error?  I remember having some discussion about this last year and think somebody came up with a very interesting example of where the former might be useful.</div></div></blockquote><div><br></div><div>Last year&#39;s discussion totally eludes me for some reason. But sure, if deferring the error until runtime is actually useful then why not? In the absence of an interesting use case, though, I think it&#39;d be nice for the compiler to warn you that Base1 &amp; Base2 is not going to be what you want.</div></div></div></div></div></blockquote><div><br></div></span><div>Deferring to runtime isn’t what I mean.  If you try to actually *do* anything that requires an instance of `Base1 &amp; Based` (which you almost always would) you would still get a compile time error.</div><div><br></div><div>I managed to dig up the example from last year’s thread and it is definitely a good one:</div><div><br></div><div>func intersection&lt;T, U&gt;(ts; Set&lt;T&gt;, us: Set&lt;U&gt;) -&gt; Set&lt;T &amp; U&gt;</div><div><br></div><div>The desire is that we are always able to produce a result set.  When T &amp; U is uninhabitable it will simply be an empty set just like Set&lt;Never&gt; has a single value which is the empty set.</div></div></div></blockquote><div><br></div><div>Currently, Set&lt;Never&gt; is impossible because Never is not Hashable :)</div></div></div></div></div></blockquote><div><br></div></span><div>Ahh, good point.  I hadn’t tried it.  It can easily be made Hashable with a simple extension though - this code compiles today:</div><div><br></div><div>extension Never: Hashable {<br>    public var hashValue: Int { <wbr>return 0 }<br>}<br>public func ==(lhs: Never, rhs: Never) -&gt; Bool { return false }<br>let s = Set&lt;Never&gt;()</div><span class=""><div><br></div><blockquote type="cite"><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_extra"><div class="gmail_quote"><div>Since concrete types *can&#39;t* be used, this example seems like it&#39;d be of little use currently. How widely useful would it be to have an intersection facility such as this when T != U even if that restriction were lifted, though? Seems like the only real useful thing you can do with generic Set&lt;T &amp; U&gt; is based on the fact that it&#39;d be Set&lt;Hashable&gt;. Other than those immediate thoughts, I&#39;ll have to think harder on this.</div></div></div></div></blockquote><div><br></div></span><div>Sure, it’s possible that this is the only interesting example and may not have enough value to be worthwhile.  But I found it interesting enough that it stuck around in the back of my mind for 8 months! :) </div></div></div></blockquote><div> </div><div>Hmm, it had not occurred to me: instantiating a Set&lt;Hashable&gt; is not supported (and you can substitute for Hashable any protocol you want). Thus, for any Set&lt;T&gt; and Set&lt;U&gt; that you can actually instantiate, unless T and U are both classes and one inherits from the other (in which case the generic `intersection&lt;X&gt;(a: Set&lt;X&gt;, b: Set&lt;X&gt;) -&gt; Set&lt;X&gt;` already suffices), Set&lt;T &amp; U&gt; must be the empty set. This is not a very interesting result.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div>It generalizes easily to any cases where you have a generic type that is useful despite not necessarily having access to instances of the parameterized type.</div><div><br></div><div>If we allow this, I *think* all uninhabitable types could be unified semantically by making `Never` a protocol and giving them implicit conformance.</div><span class=""><br><blockquote type="cite"><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><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"><div style="word-wrap:break-word"><div><div>This example points even more strongly in the direction of allowing *any* concrete type to be used, not just classes - even today we could produce uninhabitable existentials like this using value types.</div><div><br></div><div>Here’s the link to the thread:<span class="m_452239474072986915Apple-converted-space"> </span><a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160523/019463.html" target="_blank">https://lists.swift.<wbr>org/pipermail/swift-evolution/<wbr>Week-of-Mon-20160523/019463.ht<wbr>ml</a></div><span><br><blockquote type="cite"><div><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="auto"><span class="m_452239474072986915m_3246467056528599417gmail-"><blockquote type="cite"><div><div class="gmail_quote"><div dir="ltr">On Sun, Jan 29, 2017 at 12:41 Austin Zheng &lt;<a href="mailto:austinzheng@gmail.com" target="_blank">austinzheng@gmail.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">The &quot;class comes first&quot; requirement made more sense when the proposed syntax was still &quot;Any&lt;T, U, V&gt;&quot;, intentionally mirroring how the superclass and conformances are declared on a class declaration (the archives contain more detailed arguments, both pro and con). Now that the syntax is &quot;T &amp; U &amp; V&quot;, I agree that privileging the class requirement is counterintuitive and probably unhelpful.<br class="m_452239474072986915m_3246467056528599417gmail-m_-1279302232438251699gmail_msg"><br class="m_452239474072986915m_3246467056528599417gmail-m_-1279302232438251699gmail_msg">Austin<br class="m_452239474072986915m_3246467056528599417gmail-m_-1279302232438251699gmail_msg"><br class="m_452239474072986915m_3246467056528599417gmail-m_-1279302232438251699gmail_msg">&gt; On Jan 29, 2017, at 10:37 AM, Matt Whiteside via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="m_452239474072986915m_3246467056528599417gmail-m_-1279302232438251699gmail_msg" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br class="m_452239474072986915m_3246467056528599417gmail-m_-1279302232438251699gmail_msg">&gt;<br class="m_452239474072986915m_3246467056528599417gmail-m_-1279302232438251699gmail_msg">&gt; Thanks for writing this proposal David.<br class="m_452239474072986915m_3246467056528599417gmail-m_-1279302232438251699gmail_msg">&gt;<br class="m_452239474072986915m_3246467056528599417gmail-m_-1279302232438251699gmail_msg">&gt;&gt; On Jan 29, 2017, at 10:13, Xiaodi Wu via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="m_452239474072986915m_3246467056528599417gmail-m_-1279302232438251699gmail_msg" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br class="m_452239474072986915m_3246467056528599417gmail-m_-1279302232438251699gmail_msg">&gt;&gt;<br class="m_452239474072986915m_3246467056528599417gmail-m_-1279302232438251699gmail_msg">&gt;&gt; As Matthew mentioned, the rules can certainly later be relaxed, but given that this proposal has the compiler generating fix-its for subclasses in second position, is there a reason other than stylistic for demanding MyClass &amp; MyProtocol instead of MyProtocol &amp; MyClass?<br class="m_452239474072986915m_3246467056528599417gmail-m_-1279302232438251699gmail_msg">&gt;&gt;<br class="m_452239474072986915m_3246467056528599417gmail-m_-1279302232438251699gmail_msg">&gt;&gt; From a naive perspective, it seems that if the compiler understands my meaning perfectly, it should just accept that spelling rather than complain.<br class="m_452239474072986915m_3246467056528599417gmail-m_-1279302232438251699gmail_msg">&gt;<br class="m_452239474072986915m_3246467056528599417gmail-m_-1279302232438251699gmail_msg">&gt; I had that thought too.  Since ‘and’ is a symmetric operation, requiring the class to be in the first position seems counter-intuitive.<br class="m_452239474072986915m_3246467056528599417gmail-m_-1279302232438251699gmail_msg">&gt;<br class="m_452239474072986915m_3246467056528599417gmail-m_-1279302232438251699gmail_msg">&gt; -Matt<br class="m_452239474072986915m_3246467056528599417gmail-m_-1279302232438251699gmail_msg">&gt;<br class="m_452239474072986915m_3246467056528599417gmail-m_-1279302232438251699gmail_msg">&gt; ______________________________<wbr>_________________<br class="m_452239474072986915m_3246467056528599417gmail-m_-1279302232438251699gmail_msg">&gt; swift-evolution mailing list<br class="m_452239474072986915m_3246467056528599417gmail-m_-1279302232438251699gmail_msg">&gt;<span class="m_452239474072986915m_3246467056528599417Apple-converted-space"> </span><a href="mailto:swift-evolution@swift.org" class="m_452239474072986915m_3246467056528599417gmail-m_-1279302232438251699gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="m_452239474072986915m_3246467056528599417gmail-m_-1279302232438251699gmail_msg">&gt;<span class="m_452239474072986915m_3246467056528599417Apple-converted-space"> </span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="m_452239474072986915m_3246467056528599417gmail-m_-1279302232438251699gmail_msg" target="_blank">https://lists.swift.org/mail<wbr>man/listinfo/swift-evolution</a><br class="m_452239474072986915m_3246467056528599417gmail-m_-1279302232438251699gmail_msg"><br class="m_452239474072986915m_3246467056528599417gmail-m_-1279302232438251699gmail_msg"></blockquote></div></div></blockquote><blockquote type="cite"><div><span>______________________________<wbr>_________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailma<wbr>n/listinfo/swift-evolution</a></span></div></blockquote></span></div></blockquote></div></div></div></div></blockquote></span></div></div></blockquote></div></div></div></blockquote></span></div><br></div></blockquote></div><br></div></div>