Smarter overload selection

[WhitWaldo]

I was just putting together a test method for an extension method when I realized that it didn't work conceptually as I imagined. I had the following in my extensions class:

public static class MyExtensions
{
  public static IServiceCollection AddMyClient(this IServiceCollection serviceCollection, Action<ClientBuilder>? configure = null)
  {
    if (configure is not null) //if it is, it's ignored
    {
       //Do something
    }
  }

  public static IServiceCollection AddMyClient(this IServiceCollection serviceCollection, Action<IServiceProvider, ClientBuilder>? configure = null)
  {
    if (configure is not null)  //if it is, it's ignored
    {
       //Do something
    }
  }
}

In my test application, I did a double take when I saw Visual Studio put a red squiggly under this:

builder.Services.AddMyClient(); 

My theory is that it doesn't know which of the overloads to use here because while they both default to null, the compiler isn't smart enough to know that it doesn't matter which it selects, so it needs the arguments passed (even if they're just discarded), so it knows which to select:

builder.Services.AddMyClient(_ => {});

This selects the first overload and assigns the action, so even though it doesn't do anything, it's also not null (so this might take an unexpected path based on the implementation).

After reading @HaloFour 's answer below, it clicked for me that of course, there might be something different going in each method so just because it's null, they're still potentially quite different things, so I went back and looked at my implementation. I think the proposal would work well enough (or as I did, just add an overload that doesn't have the Action argument at all, problem solved).

While it's a much more complex scenario than originally described (I've updated the code above), fundamentally, it'd still be nice if the compiler were a tad bit smarter - instead of just looking at the method signatures, exclusively when it's ambiguous like this, peek inside the method to see if there's any difference in how that argument is used and if it's used differently between the two. If there is, there's nothing to be done - as we're back in the original scenario. But here, the exact same thing happens - if configure is null, it's ignored, if it is isn't, something happens. So between the two methods, it really doesn't matter which of the two runs because if null, either would yield the same outcome.

Updated to better reflect the scenario I was looking at when I first wrote this.

[HaloFour]

I believe the overload resolution priority proposal will cover this, in that you can specify which of the two methods would be preferred in the case of ambiguity.

[colejohnson66]

How is the compiler supposed to know which is better? For all it knows, the Action<ClientBuilder> and Action<IServiceProvider, ClientBuilder> methods could do wildly different things. As @HaloFour said, the overload resolution priority proposal allows you to tell the compiler which is which.

[CyrusNajmabadi]

the compiler isn't smart enough to know that it doesn't matter which it selects

Why would it not matter? You have two different methods. It has to pick one, so you'll get a different program that behaves a different way depending on which it picks.

[CyrusNajmabadi]

In my updated scenario, it's ambiguous which method should be used because of an Action argument that takes a different number of arguments in each and defaults to null. In the method bodies, if the argument is null, it's ignored, so in this scenario, they are fundamentally identical

I don't know what this means. How are they 'fundamentally identical'? Just because each ignores an argument (which isn't something that could ever be known in the first place (consider metadata)), doesn't mean the rest of the methods are the same.

Here's an example:

void DoSomething(int i, Action<int> a = null) {
    DeleteHardDrive();
}

void DoSomething(int i, Action<int, int> a = null) {
    SendEmail();
}

Just because both of these take an optional second argument doesn't mean they are 'functionally identical'.

[CyrusNajmabadi]

and have it pick either of the overloads as they're both null.

But if one deletes your hard drive, and hte other sends an email, then then picking one vs the other could be very bad. You're effectively saying: infer that because a parameter is optional that otherwise the method behaves teh same way. But that's not how methods work at all.

[WhitWaldo]

That's right, but take my revised example above:

void DoSomething(int i, Action<int> a = null) {
  if (a is null)
    return;

  DeleteHardDrive();
}

void DoSomething(int i, Action<int, int> a = null) {
  if (a is null)
    return;

  SendEmail();
}

From the signatures themselves, it's ambiguous and we're on the same page. But peek inside the method and examine what happens if the default value is set and if it's identical, it doesn't matter that the rest of the method varies, because exactly the same thing will happen regardless of which is picked.

[CyrusNajmabadi]

But peek inside the method

That's not a concept. Precisely for the reason i mentioned above. There is no mechanism to 'peek inside the method'. Consider something as trivial as metadata, and a ref-assembly. There is no 'inside' to know abotu at all. All you have is the signature. That's what defines the contract. The insides are completely unknown and unknowable.