"Actors are reference types, but why classes?"

[Chris_Lattner3 (Chris Lattner)]

@Douglas_Gregor

@George

I like the simplicity of “I want to isolated state” meaning I use an actor, and “I want subclassing” meaning I a class, and “I want both” meaning I use an actor, wrapping a class (Maybe I feel the slight sting of an extra indirection, but we all have to make sacrifices).

This kind of wrapping involves a ton of boilerplate. You mentioned copy-on-write types as prior art here, but I see that more as a cautionary tale: there’s a lot of boilerplate that you have to get right, and one missed copy-on-mutation makes for annoying bugs

This is only true if you have OO subclassing situations already. Why do you think that concurrency equates so strongly to OO subclassing?

@Douglas_Gregor

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.

I didn't phrase my response earlier very well, and on reflection it looks like I worded it overly strong. I'm sorry for that, I didn't mean to get overly excited, I'll try to keep tone in better check in the future.

The thing I'm observing is that you seem to have a default mental association of "actors are a kind of class" that pervades your writing. Consider your post that I was reacting to:

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

You are defining actors as classes by saying "actor (class)", but they aren't definitionally classes, this is something we get to decide. They are only definitionally "a reference semantic thing", which is what the whitepaper tries to point out. We get to choose both 1) their behavior/capabilities, and 2) how we explain them to Swift programmers.

What I'm observing is that there is no inherent reason for actors to provide subclassing capabilities. If that is removed, then actors are clearly not classes. In my opinion, this is a beneficial thing, because they are already "not like classes" in other ways, and this divide makes the language behavior more clear and allows us to (continue) pushing programmers away from OO and subclassing as the preferred way to model their apps.

@Douglas_Gregor

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

Your points are all objections to protocol oriented programming in general. As you mention, we already have reason to make protocols more powerful, further reducing the relative power and importance of classes.

@Douglas_Gregor

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.

Again, I can understand where you're coming from here, but this explanation only makes sense if you have already decided that "actors are classes". If you break that association, then the explanation above doesn't make as much sense (to me at least).

-Chris