[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