<div dir="ltr">On Sun, Jan 29, 2017 at 1:37 PM, Matthew Johnson <span dir="ltr"><<a href="mailto:matthew@anandabits.com" target="_blank">matthew@anandabits.com</a>></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="gmail-"><div><br>On Jan 29, 2017, at 12:58 PM, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> 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 & Protocol1 and Bar = Base & Protocol2, it'd be nice to allow Foo & Bar.<br><br>It'd be nice to go one step further: given class Derived : Base, if I have typealiases Foo2 = Base & Protocol1 and Bar2 = Derived & Protocol2, then it could be permitted to write Foo2 & 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 & Base2 would make your existential type essentially equivalent to Never. But Base1 & Base1 & Base1 is fine for the type system, the implementation burden (though greater) shouldn'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 & 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'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'd be nice for the compiler to warn you that Base1 & Base2 is not going to be what you want.</div><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="gmail-"><blockquote type="cite"><div><div class="gmail_quote"><div dir="ltr">On Sun, Jan 29, 2017 at 12:41 Austin Zheng <<a href="mailto:austinzheng@gmail.com" target="_blank">austinzheng@gmail.com</a>> 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 "class comes first" requirement made more sense when the proposed syntax was still "Any<T, U, V>", 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 "T & U & V", I agree that privileging the class requirement is counterintuitive and probably unhelpful.<br class="gmail-m_-1279302232438251699gmail_msg">
<br class="gmail-m_-1279302232438251699gmail_msg">
Austin<br class="gmail-m_-1279302232438251699gmail_msg">
<br class="gmail-m_-1279302232438251699gmail_msg">
> On Jan 29, 2017, at 10:37 AM, Matt Whiteside via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail-m_-1279302232438251699gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="gmail-m_-1279302232438251699gmail_msg">
><br class="gmail-m_-1279302232438251699gmail_msg">
> Thanks for writing this proposal David.<br class="gmail-m_-1279302232438251699gmail_msg">
><br class="gmail-m_-1279302232438251699gmail_msg">
>> On Jan 29, 2017, at 10:13, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail-m_-1279302232438251699gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="gmail-m_-1279302232438251699gmail_msg">
>><br class="gmail-m_-1279302232438251699gmail_msg">
>> 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 & MyProtocol instead of MyProtocol & MyClass?<br class="gmail-m_-1279302232438251699gmail_msg">
>><br class="gmail-m_-1279302232438251699gmail_msg">
>> 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="gmail-m_-1279302232438251699gmail_msg">
><br class="gmail-m_-1279302232438251699gmail_msg">
> 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="gmail-m_-1279302232438251699gmail_msg">
><br class="gmail-m_-1279302232438251699gmail_msg">
> -Matt<br class="gmail-m_-1279302232438251699gmail_msg">
><br class="gmail-m_-1279302232438251699gmail_msg">
> ______________________________<wbr>_________________<br class="gmail-m_-1279302232438251699gmail_msg">
> swift-evolution mailing list<br class="gmail-m_-1279302232438251699gmail_msg">
> <a href="mailto:swift-evolution@swift.org" class="gmail-m_-1279302232438251699gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail-m_-1279302232438251699gmail_msg">
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail-m_-1279302232438251699gmail_msg" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br class="gmail-m_-1279302232438251699gmail_msg">
<br class="gmail-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/<wbr>mailman/listinfo/swift-<wbr>evolution</a></span><br></div></blockquote></span></div></blockquote></div><br></div></div>