[swift-evolution] Class and Subclass Existentials (Round 2)

[Joe Groff]

> On Feb 9, 2017, at 4:26 AM, Step Christopher via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Looks good. Minor comments below:
> 
>> let t: P & C // Compiler error: subclass contraint must be in first position
> 
> Typo: contraint should be constraint
>>  <https://github.com/hartbit/swift-evolution/blob/e6411d8a9e7924bbd8a48fc292bf08d58a8d1199/proposals/XXXX-subclass-existentials.md#3-when-a-protocol-composition-type-contains-a-typealias-the-validity-of-the-type-is-determined-using-the-following-steps>
>> ...
>> typealias TA4 = D & P2
>> typealias TA5 = E & P2
>> 
>> typealias TA5 = TA1 & TA2
>> typealias TA5 = class & P1 & class & P2 // Expansion
>> typealias TA5 = class & P1 & P2 // Normalization
>> // TA5 is valid
> 
> The typealias 'T5' is repeated as both an initial composition, and as a demonstration of combining typealiases. 
> 
> 
>> This proposal merges the concepts of class and AnyObject, which now have the same meaning: they represent an existential for classes. They are four solutions to this dilemna:
>> Do nothing.
>> Replace all uses of AnyObject by class, breaking source compatibility.
>> Replace all uses of class by AnyObject, breaking source compatibility.
>> Redefine AnyObject as typealias AnyObject = class.
> 
> I agree with other comments on recommending 4 here, and covering the others as alternatives
>>  <https://github.com/hartbit/swift-evolution/blob/e6411d8a9e7924bbd8a48fc292bf08d58a8d1199/proposals/XXXX-subclass-existentials.md#source-compatibility>I agree that we need the typealias for compatibility. I think it's still worth discussing whether the `AnyObject` typealias should *only* be there for compatibility; it could be deprecated or obsoleted in Swift 4 or future language versions.

-Joe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170209/fd64d4d3/attachment.html>