Class-only protocols, class vs AnyObject?

Jens · March 30, 2018, 7:41am

What is the difference, if any, btw P and Q here:

protocol P : class { ... }

protocol Q : AnyObject { ... }

If no difference, which should be preferred?

(I got the impression that the class version was meant to be deprecated, but it still compiles without warnings as of Xcode 9.3)

tkrajacic · March 30, 2018, 8:21am

See https://stackoverflow.com/questions/30176814/whats-the-difference-between-a-protocol-extended-from-anyobject-and-a-class-onl/32895975#32895975 for a subtle difference, but yes it has been stated that it will be removed. I also don’t know why it wasn’t deprecated in this release.

Jens · March 30, 2018, 9:06am

Thanks, If the following (from @codafi’s stack overflow answer) is true:

The difference lies in the semantics of @objc declarations. With AnyObject, the expectation is that conforming classes may or may not be proper Objective-C objects, but the language treats them as such anyway (in that you lose static dispatch sometimes).

Does this mean that inheriting from AnyObject might incur a performance overhead (compared to if class had been used)?

Slava_Pestov · March 30, 2018, 9:06am

The StackOverflow answer is out of date as of Swift 4. protocol P : class {} and protocol P : AnyObject {} parse identically and there’s no semantic difference between them. We should add a warning to deprecate the former at some point.

fabb · June 13, 2018, 9:01am

The StackOverflow answer is out of date as of Swift 4. protocol P : class {} and protocol P : AnyObject {} parse identically and there’s no semantic difference between them. We should add a warning to deprecate the former at some point.

But even @jrose prefers class in his WWDC 2018 talk

Tino · June 13, 2018, 9:06am

It's just fair that Swift Evolution not only breaks users code, but also creators slides ;-)

jrose · June 13, 2018, 4:21pm

Oof, my bad. Should have had Slava review them first!

Jon_Shier · June 13, 2018, 5:45pm

Don't worry, you weren't the only presenter with imperfect Swift code. I'm pretty sure I remember a session where the presenter typed out -> Void return types. It's fairly clear that many Apple's still aren't that familiar with Swift. For some, I'm guessing WWDC slides and presentations may be the only time they write Swift at all. At least I haven't noticed any semicolons this year!

Vyacheslav · July 24, 2018, 4:24pm

Which keyword is preferred? Assumed that seems 'class' behaves incorrectly, is AnyObject better? Will class be deprecated?

DevAndArtist · July 24, 2018, 4:42pm

Both are the same, class is deprecated in favor of AnyObject simply without a warning. See Slavas response above.

Slava_Pestov · July 25, 2018, 9:12pm

Both keywords behave identically. AnyObject is preferred because it is the name of a type and can appear anywhere that a type can. "class" is just special syntax in that one place in a protocol's inheritance clause, and it parses identically to "AnyObject".

smashkins · February 6, 2019, 7:03pm

Quoting Matt Neuburg:

A protocol declared with the keyword class after the colon after its name is a class protocol, meaning that it can be adopted only by class object types:
protocol SecondViewControllerDelegate : class {
    func accept(data:Any!)
}
(There is no need to say class if this protocol is already marked @objc; the @objc attribute implies that this is also a class protocol, because classes are the only Objective-C object type.)
A typical reason for declaring a class protocol is to take advantage of special memory management features that apply only to classes

class SecondViewController : UIViewController {
weak var delegate : SecondViewControllerDelegate?
// ...
}
The keyword weak marks the delegate property as having special memory management that applies only to class instances. The delegate property is typed as a protocol, and a protocol might be adopted by a struct or an enum type. So to satisfy the compiler that this object will in fact be a class instance, and not a struct or enum instance, the protocol is declared as a class protocol.
In Swift 4 or later, you might alternatively take advantage of classprotocol composition to accomplish the same thing:
class SecondViewController : UIViewController {
    weak var delegate : (NSObject & SecondViewControllerDelegate)?
    // ...
}
That's legal even if SecondViewControllerDelegate has no class designation, because the compiler knows that the object assigned to the delegate property will derive from NSObject, in which case it is a class instance.

But... the 0156 proposal says:

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.

0156 proposal

pepejeria · November 6, 2020, 8:57am

Is this information still valid? Should we avoid using class and use AnyObject instead?

donny_wals · November 6, 2020, 9:13am

Yes

Slava_Pestov · November 17, 2020, 2:04am

You can use either one, but I suggest using AnyObject since it can be used in more places (such as protocol compositions, eg MyProto & AnyObject). Also I’d like us to add a warning that class is deprecated at some point (this would make for a great starter bug if anyone is interested).