"Actors are reference types, but why classes?"

[xwu (Xiaodi Wu)]

@Douglas_Gregor

tl;dr: the only thing that makes an actor (class) different from a class is that an actor (class) protects its state from data races, so they should be exactly that: nothing less, nothing more.

< snip >

The subclassing rule is not some fundamental difference in types; it is a direct consequence of protecting actor state. If an actor class were to inherit from a non-actor class, it would mean that the whole of the actor class's state has not been protected against data races, because one could easily have data races through the superclass. That would undercut the actor model.

< snip >

So, this subclassing restriction isn't a rigid dividing line, it's a consequence of the one thing actor classes do differently from classes, which is to protect their state from data races.

Forgive me, but it seems there’s some circularity to the argument here.

Why conceptualize actors as classes with only this one difference? Because it allows users to understand and use every other aspect of classes, including subclassing, on actors.

Why allow subclassing and every other aspect of classes to be available for actors? Because it allows them to differ from classes only in one thing.

It would seem to me axiomatically true that a explaining actors in terms of classes brings more complexity and a higher barrier to mastery than not explaining actors in terms of classes. While some users work extensively with class hierarchies in Swift, others do not.

I would be lying if I pretended not to review convenience/designated initialization rules every so often when questions arise here about classes. It would be unfortunate if using one of the major tentpole features of Swift concurrency required this sort of review: there is nothing about protecting state from data races that is conceptually built on that knowledge.