[swift-evolution] Subclass Existentials
David Sweeris
davesweeris at mac.com
Wed Feb 1 17:11:55 CST 2017
> On Feb 1, 2017, at 3:01 PM, David Hart via swift-evolution <swift-evolution at swift.org> wrote:
>
>
> On 1 Feb 2017, at 22:54, Douglas Gregor <dgregor at apple.com <mailto:dgregor at apple.com>> wrote:
>
>>
>>> On Jan 29, 2017, at 8:44 PM, Slava Pestov via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> 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?
- Dave Sweeris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170201/f52077ed/attachment.html>
More information about the swift-evolution
mailing list