This proposal is looking really great John, I love the clear problem description and motivation. Thank you for writing this up.
I only have a few minor comments/suggestions:
The
Reftypes are themselves value types, but they hold references to actors and executors, both of which must be reference types. It’s because of that (conceptual, not physical) indirection that I thought theRefsuffix would be clarifying.
I think we typically use the word "Pointer" for that. This was what we decided when designing UnsafeBufferPointer ages ago.
The type of the property must be convertible to
Actor.
Not related to this proposal I suppose, but should the Actor protocol be named AnyActor?
serialExecutorwill be synthesized aspublic final
How does this affect resilience and evolution of the actor? Making this final seems to be a different default, preventing subclasses from controlling their executor nature.
In "Explicit scheduling", the closures should be marked @concurrent.
The proposed ways for actors to opt in to custom executors are brittle, in the sense that a typo or some similar error could accidentally leave the actor using the default executor.
Why not tie this into protocol conformance? Someone making an explicit statement (by conforming to a "has custom executor" protocol would make it clear if they mess up the implementation.
-Chris