"Actors are reference types, but why classes?"

[Douglas_Gregor]

@Chris_Lattner3

Right, but I think you're missing the observation here. I understand that you've intentionally carved actors away from classes as a "different thing" that doesn't interoperate with them. This underscores my point that programmers should think about and design towards them being different concepts.

You're misinterpreting my point: the proposal simplifies the rule by separating actor class and non-actor class hierarchies. You're interpreting that as evidence that "these two things must be completely different," when it is not: it's a simplification of the more precise rule I stated.

@Chris_Lattner3

Classes were constrained by a wide range of concerns that don't affect actors, including a VERY long list of Objective-C framework compatibility issues that drove a lot of complexity into initialization semantics and many other parts of the system

Subclassing introduces complexity, but beyond the inheritance of initializers, you really can't blame Objective-C for any of it. The argument that "we don't have Objective-C so we don't need subclassing" doesn't follow.

@Chris_Lattner3

As others have mentioned upthread, the complexity of subclassing for actors should be justified from first principles, based on what the enable. I don't think the "they are reference types therefore they should inherit all the problems of classes" necessarily carries over.

The reasons for subclassing are identical for actors and classes. It provides implementation inheritance and shared storage for subclasses (something people ask for protocols to do). Subclassing provides more efficient dynamic subtyping checks (as? to a subclass will always be much faster than as? to a protocol) and cheaper existentials (one pointer vs. 1+number of protocols pointers).

And existing class hierarchies that make use of these features can migrate over to actor classes if actor classes support subclassing. Take away subclassing and you're forcing folks to rewrite more code to adopt concurrency. Have we improved their experience, or have we thrust our own opinions on them?

@Chris_Lattner3

After all, functions are reference types as well and don't get the problems of classes, why should the /third/ reference type get them? (*)

They get all of the problems of shared mutable state. They don't run into any of the other issues with subclassing because there aren't meaningful dynamic subtyping relationships, nor do they conform to protocols.

@Chris_Lattner3

(*) And here I'm ignoring indirect enums which live in yet another half way zone between all the things that shows that reftypes != inheritance.

Those are value types with a different storage mechanism, not reference types.

I really, really do understand why folks don't like subclassing. I wouldn't choose to have it in a language, but it's there now, and it will not be going away. It solves real problems for Swift developers, and they use it. And if you don't like it, it doesn't hurt you: final takes it away and you've lost nothing, and for the most part you don't even need to write final for subclassing to be irrelevant if you don't use it.

Doug