Implement IRepliable?

[Horusiath]

The idea is to create a separate interface IRepliable { replyTo: ICanTell } which would be implemented by messages that are expected to wait for response from actor processing the message. This way we could eventually drop support for Sender property (this is quite error prone) and limit the range of <? operator (to be used only when combined with repliable messages).

[raymens]

So if I read this correctly, you'd like to improve sending the reply that's currently something like: mailbox.Sender() <! "someReply"?

[Horusiath]

Basically yes. Problem with Sender() is that it's mutable (which makes using it risky within eventual async operations executed inside an actor) and that you actually are never sure, if you're supposed to reply to sender when a handling a message or not.

Marking messages with Repliable interface gives a suggestion, that message should be replied. Moreover if replyTo field would be using typed version of ICanTell<'t>, that would also tell what type of response is expected.

This idea also comes from akka-typed module on the JVM.

[raymens]

Then this would get a big +1 from me, as I've always thought the current implementation was just wrong. Have you already done some partial work on this in a branch?

[Neftedollar]

It's awesome!
Is this issue is still actual?

[daniellittledev]

I've seen a lot of resistance in the past adding external dependencies to message contract libraries. Would this also require messages to be mutable? Or more than a simple record?

[Horusiath]

@Neftedollar @lavinski the idea here is quite simple, but I guess it needs to be implemented on Akka level to actually bring not only compile time verification, but also performance benefit.

Essential code looks like this:

interface IRepliable<TReply> { IActorRef<TReply> ReplyTo { get; } }

static Task<TReply> Ask<TReq, TReply>(this ICanTell<TReq> target, TReq request) 
    where TReq : IRepliable<TReply> { ... }

This way compiler could make sure, that all communicating sides will be able to handle each other's messages.

However there are some problems with that:

• Right now we have Sender field that we use to store requester anyway. So we don't have any performance benefit here.
• This particular Ask version will break C# generic type inference: C# compiler won't be able to infer generics, so they will have to be passed explicitly, which is gross.
• On the F# side you cannot write mutual generic constraints between two generic types.
• Also for F# this would require to annotate messages with IRepliable<> interface which may be neutral for records, but it's totally horrible if you have to implement it on the discriminated union.