> On Feb 28, 2017, at 1:19 PM, Jordan Rose via swift-evolution
> <[email protected]> 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
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
