[swift-evolution] Class and Subclass Existentials (Round 2)
jgroff at apple.com
Thu Feb 9 12:47:03 CST 2017
> 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
>> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution