Sent from my iPad
> On Feb 1, 2017, at 5:11 PM, David Sweeris via swift-evolution > <[email protected]> wrote: > > >> On Feb 1, 2017, at 3:01 PM, David Hart via swift-evolution >> <[email protected]> wrote: >> >> >> On 1 Feb 2017, at 22:54, Douglas Gregor <[email protected]> wrote: >> >>> >>>> On Jan 29, 2017, at 8:44 PM, Slava Pestov via swift-evolution >>>> <[email protected]> wrote: >>>> >>>> This is a nice generalization of the existing protocol composition syntax. >>>> Implementation might get a little tricky — this touches a lot of things, >>>> such as inheritance clauses, constraints in generic signatures, and casts. >>>> It would require thorough testing. >>>> >>>> There are also a few odd corner cases to sort out: >>>> >>>> typealias T = SomeClass & SomeProtocol >>>> >>>> class C : T { // should we allow this? probably yes >>>> } >>>> >>>> protocol P : T { // should we allow this? probably no >>>> } >>> >>> IIRC, we already allow the latter where T is a typealias for SomeProtocol1 >>> & SomeProtocol2. Why not allow it generally? >> >> Well what would it mean? A protocol can't inherit or conform to a class. > > That anything which conforms to that protocol must subclass SomeClass? Yes, this is exactly what I would expect. I was calling it a supertype requirement earlier in the thread. > > - Dave Sweeris > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
