Class-only protocols, class vs AnyObject?

[Jens]

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 (Thomas Krajacic)]

See swift - What's the difference between a protocol extended from AnyObject and a class-only protocol? - Stack Overflow 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]

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]

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 (Fabian)]

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]

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

[jrose (Jordan Rose)]

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

[Jon_Shier]

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]

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

[DevAndArtist (Adrian Meister)]

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

[Slava_Pestov]

@Vyacheslav

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

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]

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 (José)]

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

[donny_wals (donny)]

Yes

[Slava_Pestov]

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).

[wristbands]

As of today, class is now officially deprecated in favor of AnyObject.