Sent from my iPad
> On Jan 29, 2017, at 12:58 PM, Xiaodi Wu via swift-evolution > <swift-evolution@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 <austinzh...@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@swift.org> wrote: >> > >> > Thanks for writing this proposal David. >> > >> >> On Jan 29, 2017, at 10:13, Xiaodi Wu via swift-evolution >> >> <swift-evolution@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@swift.org >> > https://lists.swift.org/mailman/listinfo/swift-evolution >> > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
