> On Feb 9, 2017, at 4:26 AM, Step Christopher via swift-evolution > <[email protected]> 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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
