I'd recommend separating the discussion of inheritance into three possible levels. It is equally valid to choose any of these paths for actors:
- No support for inheritance.
- Support for inheritance but without designated/required initializers, class methods, etc.
- The full model that Swift supports for classes (as the proposal suggests).
The model Swift has for classes (#3) is extremely complicated due to compatibility issues with legacy Objective-C design patterns that we had to embrace in Cocoa (e.g. things like CoreData), which have nothing to do with actors. I don't see any defensible reason to bring this complexity to actors unmodified.
The few arguments I've heard in favor of inheritance for actors (including those above) are for #2. Such a simplified model for actor inheritance could be built and would not carry with it all the cons of #3. However, we don't have such a design on the table today, and I don't think we want to slow down the actor feature itself to design, build, and prototype it out.
The natural solution to this is to start with actors that do not support inheritance. If there is a compelling reason to add it in the future, then we can evaluate the best path to doing so (e.g. a #2 model) and add that extension in time. This would be based on practical experience with Actors, not proactively adding complexity in case it is useful.
In terms of "language evolution over time", it is much easier to expand a small feature than to take away power from a larger feature.
-Chris