Why overridden overloads won't contribute to overload resolution?

[alrz]

Consider:

class Base<T> where T : struct {
    public virtual void M(T v) { }
}
class Derived<T> : Base<T> where T : struct {
    public override void M(T v) { }
    public void M(T? v) {
        this.M(default(T)); // resolves to Derived<T>.M(T?)
    }
}

Even though a more specific overload "exists" as Derived<T>.M(T) it does not contribute to the overload resolution on the invocation.

The workaround is to cast this to the base ((Base<T>)this) which is weird. Is this called out in the spec?

[svick]

Is this called out in the spec?

Yes:

A member lookup of a name N […] in a type T is processed as follows:

• First, a set of accessible members named N is determined:
  • […] Members that include an override modifier are excluded from the set.

[alrz]

Thanks. That doesn't make it less weird? Particularly because it doesn't match the "closeness" concept.

[CyrusNajmabadi]

This is a great question. Here's what i remember (though i think @jaredpar may have the most knowledge/context here):

Back in the early days of the language, this rule was fine and really didn't have any negative impact. It was basically a clean way of saying "overrides" don't really matter, and you can just look at all the other decls to determine the set of things to look at. This meant, for example, that an override was not a potential duplicate for a thing it overrode.

This also matched how the compiler actually emits code. IIRC, it's just a virt-call to that topmost virt method, with the true 'real override' determined at runtime (since, after all, even if you are calling an override, at runtime there may be an even deeper override of that).

However, as the language moved forward, this 'rule' has become a bit anachronistic (IMO), and has certainly been a source of friction. Two examples of how that friction can arise are with:

1. named parameters
2. parameter defaults

Because the language never mandated that an override must match in parameter names (or defaults) users could now end up in strange (but allowed) circumstances where those attributes might differ between a member in base type vs in a derived type. For reasons, that i can't exactly remember, we ended up deciding that it was sensible that statically we would use the 'closest' override we found to determine things like how named-parameters/defaults would work (even though i believe we still emit a call to the topmost member).

As you also point out, generics also throws a wrench into this as one could sensibly construct code where they want the override to be considered the best match.

Unfortunately this is an area that, if we were to change this, feels very much like we would certainly cause breaking changes. So, it's one of those: "well, we didn't forsee this in C# 1, and now it's likely too much code depends on this. so we'll just accept this as SOP for the forseeable future".

Lacking any really critical cases where we felt warranted change here, we're likely going to stick with this for a very long time.

Sorry!

[alrz]

Yeah, just fixed a SO because the other overload was made virtual. I would not guessed it exactly because both are "closest" to the usesite.

It is also surprising because the override is considered an immediate member of the containing type in any other regard (e.g. reflection)

[jaredpar]

I don't have much to add over @CyrusNajmabadi explanation as he hit all of the big points I'm aware of.

He mentioned named and optional parameters but really the friction extends to any time when an overrides method can meaningfully differentiate from the declaration or interface method. Hence the friction extends to nullable reference types, out vs ref (that can change in overrides between languages), dynamic vs. object parameter slots (that can also change in overrides), etc ... It also can extend into analyzers cause they need to decide if they issue diagnostics based on the declaration or most derived method.

I agree if we were starting over we would likely change this decision either by which method we use for analysis or by having a much stricter definition of what is or isn't a legal overrides / interface implementation.

[jaredpar]

Here is an example of the oddness you can see because we use the declared signature for some types of validation and the most derived for others.

#nullable enable
using System;
using static System.Console;

var local = new C2();
local.M(d => d.Blah());   // Error: because we use C1.M for validation
local.M(null);            // No diagnostics because we use C2.M for NRT???
((C1)local).M(null);      // Warning: can't convert null to non-null
   

class C1 { 
    public virtual void M(Action<object> o) => WriteLine("C1.M");
}
class C2 : C1 {
    public override void M(Action<dynamic>? o) => WriteLine("C2.M");
}

Sharplab