> On Feb 9, 2017, at 10:47 AM, Joe Groff via swift-evolution > <[email protected]> wrote: >> On Feb 9, 2017, at 4:26 AM, Step Christopher via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> Looks good. Minor comments below: >> 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.
I think it might be worth keeping to provide a more sensible capitalization alternative than lower case “class” when used as a type name: var obj: class // this looks weird because of capitalization. var obj: AnyObject // this looks better. > > -Joe > _______________________________________________ > swift-evolution mailing list > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
