[swift-evolution] [swift-evolution-announce] [Review] SE-0156: Class and Subtype existentials

[Hooman Mehr]

> On Feb 28, 2017, at 1:19 PM, Jordan Rose via swift-evolution <swift-evolution at swift.org> wrote:
> 
> [Proposal: https://github.com/apple/swift-evolution/blob/master/proposals/0156-subclass-existentials.md <https://github.com/apple/swift-evolution/blob/master/proposals/0156-subclass-existentials.md>]
> 
> Well-written, good job, useful feature, long-since-needed-because-of-ObjC, +1.
> 
> One nitpick:
> 
>> This proposal merges the concepts of `class` and `AnyObject`, which now have the same meaning: they represent an existential for classes. To get rid of the duplication, we suggest only keeping `AnyObject` around. To reduce source-breakage to a minimum, `class` could be redefined as `typealias class = AnyObject` and give a deprecation warning on `class` for the first version of Swift this proposal is implemented in. Later, `class` could be removed in a subsequent version of Swift.
> 
> 'class' is a keyword, so we don't get to drop the special parsing no matter what. We can still deprecate it, but I wouldn't bother trying to jam it into a typealias.

Yeah, why bother making 

typealias class = AnyObject

compile?

We should just provide autocorrect to migrate this:

protocol P: class {}

into this:

protocol P: AnyObject {}

and warn if the old syntax is used (while continuing to support it just as it works now). We can then remove the parser rules that accept the first form (using ‘class’) in Swift 5.

Otherwise strong +1 as it is obviously needed for proper ObjC support.

> 
> Jordan
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170301/5ed6d27a/attachment.html>