Thanks for the writeups, Doug!
As we've worked through this before I very much agree with all of this and more than happy to take the proposal to the next level with this! Unless others will have much feedback here, I think I'll work this into our second version of the proposal as we work through implementing some of this in the coming weeks.
For additional context a few comments:
The DistributedFunction
type
Yes, that is perfect!
And we'd have that function(...)
crash hard if misused, in order to prevent any weird misuse. It is the transport developers responsibility to make quadruple sure things are being invoked on the right actors and with the right types.
We'll have to work out what exactly it has to contain to support a few other advanced features (like for tracing we'd want to have the "#function"
name so a trace span could use that as a nice default for the name of the trace). By lucky accident, recently there was a talk by the Reuben from the Orleans team, describing their source generator (they use source gen), and it basically is exactly that shape as well (including the pretty names for debugging/introspection), so that was a nice accidental confirmation of our design -- as I've seen it only after we came up with this actually (Though to be fair, the requirements for such systems are all the same, so yeah, similar solutions arise).
Transport or SerializationRequirement typealiases
You mentioned that it's perhaps left for another discussion, but I'll quickly say that for many reasons, this is exactly what we'd want anyway, and were aiming for eventually anyway:
protocol DistributedActor {
associatedtype ActorTransportType: ActorTransport
}
This has a small rippling effect on some of the other synthesis (type of transport accepted by initializer), but that's pretty simple and something we wanted anyway.
In practice I think we'd default to something like CodableTransport
-- by the way, perhaps time to rename this as ActorMessageTransport
and then CodableMessageTransport
which just refines it with the typealias SerializedRequirementType = Codable
Overall looking great and I think it'll work well.
I am not too concerned about the limitation on extensions -- this is fine IMHO. What matters the most is that a protocol itself does not have to specify this, and we can validate there is a specific type provided either at the concrete actor or at the time of resolving. Either being static compile time checks
In any case, this all sounds great and I'll work those into the next revision of the proposal