Conceptually I do believe that actors and classes should be separate and thus actors should be declared as 'actor' and not 'actor class'; however, I don't agree that inheritance, method overriding, designated / convenience initializers, casting, dynamic dispatch should be unavailable for actors simply because it is believed by some that we won't want or need them. There should be a strong technical reason that any individual feature should not persist in the actor specification and each of them should be evaluated for that. For example, if it would be technically problematic and in-fact dangerous to thread safety for property getters and setters to be overridden in actors as they are in classes, then they should not be included. My Thesis: Actors should be distinct reference type entities with most (if not all) the same features of classes.
Why not support subclassing?
In this section Chris refers to a quote that seems to equate subclassing with 'increased complexity', there is no evidence for this -- or the point is just not very well made; in fact I think the concepts of classes and inheritance are so well established and understood (easy to learn and teach) that 'increased complexity' should be applied to more convoluted features like generics (which are increasingly complex, difficult to teach, understand and hard to explain when analyzing a type in a simple View in SwiftUI, for example). Many times a class only overrides one or two methods in a class that contains hundreds of other methods that are not overridden -- that is hardly complex. From the standpoint of the compiler, maybe, but from the programmers perspective they are simple concepts.
In the section " Reusing classes reduces the implementation cost of the compiler", Chris makes a great point, but what he says in What are Actors? What do they require? is more important as Actors require a different model for getting and setting state in such a way that is safe; in the beginning I think that it would SEEM easy to hack actors on the code that has already been established for classes only for us to realize that it needs to be completely stripped out, duplicated and separated (in the code). That is my feeling, and may prove to be incorrect. Basically: Actors can't be a hack job on classes.
Simply put, I would like to subclass my actors. I don't prefer the dogma of 'structs+protocols+generics' as being preferred and I really don't want to be cornered into that strict paradigm. The Swift text books can suggest that not subclassing actors is preferred, but it should be available. There is no safety in the suggestion "if we decide later that we need it, we will add it." If that is the case, then just hack the features onto classes.
I really want to be able to use Swift to develop replacements for all my web/server side software. I am heavily invested in where this all goes.