Question: Overload method selection on client target

[LittleLittleCloud]

Suppose I have the following contract with overloaded methods

public interface IMyService
{
   Task<bool> UpdateAsync(ImmutableArray<string> projectInfos, CancellationToken);
   Task<bool> UpdateAsync(ImmutableArray<ProjectInfo> projectInfos, CancellationToken);
}

Which UpdateAsync should be selected if I call from client side in this way (empty projectInfos)

IMyService myServiceProxy = // get proxy
ImmutableArray<ProjectInfo> myProjectInfos = [];
await myServiceProxy.UpdateAsync(myProjectInfos, ct);

My observation is the string overload UpdateAsync is selected, is it expected behavior for JsonRPC call since the type info for parameters might not be included?

[AArnott]

The type info for arguments is never included in a JSON-RPC request. So the way overload resolution works for StreamJsonRpc is that it first filters down to overloads that accept the given number of arguments (or given named arguments). Then it begins trial deserialization and invokes the first overload for which the arguments could successfully serialize.

In the case of your empty collection, either one could be selected. The 'first' one in the viable set is undefined.

For this and performance reasons, overloads are discouraged. Particularly when their parameters allow multiple overloads to match based on argument count and/or name.

[LittleLittleCloud]

@AArnott Thanks for the response, so if I rename the parameter from projectInfos to another name, would that make the second method not an overload of the first one from JsonRPC aspect.

[tmat]

Perhaps we need an analyzer that reports warnings for such overloads.

[AArnott]

Renaming the parameter would only disambiguate the overloads for clients that send named arguments. Clients that send positional arguments have no names so it wouldn't help them. And FWIW, StreamJsonRpc's default mode as a client is to send positional arguments.

[AArnott]

Perhaps we need an analyzer that reports warnings for such overloads.

I agree. I hope to do that soon, now that we actually have an attribute to identify JSON-RPC interfaces.