Local function hides functions declared in class

[gafter]

@aka-STInG commented on Tue Feb 12 2019

Version Used:

C# 7.3 (Visual Studio 2017 15.9.6

Steps to Reproduce:

public class Mutator
{
    public int Mutate(int a, int b)
    {
        bool IsSum(int x)
        {
            return true;
        }

        if (IsSum(a, b))
        {
            return a + b;
        }
        else
        {
            return a - b;
        }
    }

    public bool IsSum(int a, int b)
    {
        return false;
    }
}

Expected Behavior:

Compilation without errors

Actual Behavior:

error CS1501: No overload for method 'IsSum' takes 2 arguments

---

@gafter commented on Tue Feb 12 2019

This is by design. The method group contains only one method, which is found in scope.

Moving to csharplang repo for any further discussion.

[Unknown6656]

As @gafter said -- this is by design.
To bypass this, use this.IsSum(....) or Mutator.IsSum(....) (if it were static) instead.

[Thaina]

I don't think this is by design

The point here is, even local function and class function is the same name, it has difference signature. It should be treat as normal overload function

[aka-STInG]

I don't think this is by design

The point here is, even local function and class function is the same name, it has difference signature. It should be treat as normal overload function

My point exactly.

[HaloFour]

Local functions don't participate in overloads. If the local function is resolved by name the compiler stops there and doesn't attempt to resolve further potential candidates. That is by design.

[aka-STInG]

It is understandable that currently it works as intended. And it is obvious that it can be fixed as proposed by @Unknown6656 or just refactored with other name. It just wonders me that with a lot of flexibility of C# (sometimes beyond good and evil like omitting type arguments etc.), this overload resolution does not work. If it is not a bug currently, maybe it can be done in future releases as new feature.

[gafter]

If we make the local function overload with members of the enclosing type, then we might get a different result than we do today. That would be a breaking change, and we would not do it even if we thought it was a good idea.

[YairHalberstadt]

@gafter
What if it only looked outside local functions if no local functions are suitable?

Not saying I want this, just throwing it at the wall.

[HaloFour]

@YairHalberstadt

What if it only looked outside local functions if no local functions are suitable?

Then you'd get into the weird situation of having to know how far the compiler is willing to coerce the type before it becomes "unsuitable" and that could be very tricky to reason about.