<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br><br>Sent from my iPad</div><div><br>On Jan 29, 2017, at 12:58 PM, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org">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><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><br><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">austinzheng@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;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_msg">
<br class="gmail_msg">
Austin<br class="gmail_msg">
<br class="gmail_msg">
> On Jan 29, 2017, at 10:37 AM, Matt Whiteside via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="gmail_msg">
><br class="gmail_msg">
> Thanks for writing this proposal David.<br class="gmail_msg">
><br class="gmail_msg">
>> On Jan 29, 2017, at 10:13, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="gmail_msg">
>><br class="gmail_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_msg">
>><br class="gmail_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_msg">
><br class="gmail_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_msg">
><br class="gmail_msg">
> -Matt<br class="gmail_msg">
><br class="gmail_msg">
> _______________________________________________<br class="gmail_msg">
> swift-evolution mailing list<br class="gmail_msg">
> <a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg">
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg">
<br class="gmail_msg">
</blockquote></div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>