[swift-evolution] Subclass Existentials

Matthew Johnson matthew at anandabits.com
Sun Jan 29 13:37:35 CST 2017



Sent from my iPad

> On Jan 29, 2017, at 12:58 PM, Xiaodi Wu via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Cool. Another avenue of improvement here is relaxing the single-class spelling rule for the sake of composing typealiases.
> 
> 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.
> 
> 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).
> 
> 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.

Yes, this is what I was indicating in my post as well.

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.

>> On Sun, Jan 29, 2017 at 12:41 Austin Zheng <austinzheng at gmail.com> wrote:
>> 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.
>> 
>> Austin
>> 
>> > On Jan 29, 2017, at 10:37 AM, Matt Whiteside via swift-evolution <swift-evolution at swift.org> wrote:
>> >
>> > Thanks for writing this proposal David.
>> >
>> >> On Jan 29, 2017, at 10:13, Xiaodi Wu via swift-evolution <swift-evolution at swift.org> wrote:
>> >>
>> >> 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?
>> >>
>> >> From a naive perspective, it seems that if the compiler understands my meaning perfectly, it should just accept that spelling rather than complain.
>> >
>> > I had that thought too.  Since ‘and’ is a symmetric operation, requiring the class to be in the first position seems counter-intuitive.
>> >
>> > -Matt
>> >
>> > _______________________________________________
>> > swift-evolution mailing list
>> > swift-evolution at swift.org
>> > https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170129/cc236e78/attachment.html>


More information about the swift-evolution mailing list