[swift-evolution] Subclass Existentials

[Matthew Johnson]

Sent from my iPad

> On Feb 1, 2017, at 5:11 PM, David Sweeris via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> 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> wrote:
>> 
>>> 
>>>> On Jan 29, 2017, at 8:44 PM, Slava Pestov via swift-evolution <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?

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
> 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/20170201/ba599240/attachment.html>