[swift-evolution] Class and Subclass Existentials (Round 2)
hooman at mac.com
Thu Feb 9 13:30:29 CST 2017
> On Feb 9, 2017, at 10:47 AM, Joe Groff via swift-evolution <swift-evolution at swift.org> wrote:
>> On Feb 9, 2017, at 4:26 AM, Step Christopher via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> 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.
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution