Local functions doesn't support method overloading

[saxus]

Method overloading is part of C#. But local functions doesn't support it. IMHO the following code should compile and work:

static void Main(string[] args)
{
    A("1");
    A(2);           // Argument 1: cannot convert from 'int' to 'string'

    void A(string a) {} ;
    void A(int a) { }; // A local variable or function named 'A' is already defined in this scope
}

[HaloFour]

This was the decision back in 2015:

For now, for prototyping purposes, we'll say that local functions are more like local variables: there can only be one of a given name, it shadows same-named things in outer scopes, and it cannot be called from a source location that precedes its declaration. We can consider loosening this later.

So I can assume that the team would be open to it given enough use cases. But I personally disagree that it should be done because method overloading exists. Method overload resolution is probably the most complicated part of the C# compiler and it's even difficult for developers to follow given the breadth of the rules when it comes to potential implicit conversions. It's trivial to give each local function a distinct name and it makes it much easier to follow that code. It's not like you can expose those functions in a public surface where overloading might provide improved ergonomics.

I'd have to see actual use cases where overloading on local functions makes an actual difference but I suspect that such code would have various design smells and be overly complicated.

[saxus]

The current situation when I found this: I had some conversion methods in local functions. The output was the same (int), and the input was ISomething or a Guid which identifies one kind of ISomething. Why? Because the business and speed requirements.

The conversions was unique in context of the whole project even in the class. It belonged to one specific method.

Something like this:

IEnumerable<SomeResult> GenerateResult(
  ISomething object
  IReadOnlyDictionary<Guid, IOtherThing> related) // Guid was identifier of ISomethings
)
{
  // some peraparations and other operations
  foreach (var relatedItem in related /* not necessary directly iteration*/)
  {
    // ...other code
    yield return new SomeResult(
      // ...
      something1: GetSomeDerivatedInfo(object),
      something2: GetSomeDerivatedInfo(relatedItem),
      // ...
    )
  }

  int GetSomeDerivatedInfo(Guid)
  {
    // call some external stuffs and do things
  }

  int GetSomeDerivatedInfo(IOtherThing)
  {
    // works with IOtherThing, different error handling, etc.
  }
}

Yes, pattern matching can be used here too, but then I've lost the strict typing instantly because the common type between Guid and ISomething is object.

[rbwhitaker]

I think top-level statements add an important additional facet to this conversation because there, the methods feel a little different than local functions (even though they're not).

Consider this code, which is close to something I was trying to do in the real world. I was trying to make a simple console app that had to get a few numeric inputs from users, some of which were unconstrained, and some of which had to be chosen from a specific range. This is what I tried to write:

using System;

// Main code here...

int PromptForNumber(string text)
{
    Console.Write(text);
    return Convert.ToInt32(Console.ReadLine());
}

int PromptForNumber(string text, int min, int max)
{
    while (true)
    {
        int number = PromptForNumber(text);
        if (number >= min && number <= max) return number;
    }
}

It's true, I could have chosen a different name for the second method. I might have also been able to use optional parameters in this specific case, but only because integer literals are compile-time constants. Had this been some other class, I'd have been out of luck.

But my initial inclination was an overload. Even though this isn't part of the API surface of the program, it still felt right to use the same name for two methods that were doing the same job, just with different inputs. It felt more natural here, and the overload to choose felt blindingly obvious.

But I do understand that other situations may be more complex, and method overload resolution is definitely a tricky topic.

[MadsTorgersen]

A couple of thoughts. First, I do think we're open to overloading on local functions; there's no particular reason why it shouldn't work, and people are often surprised that it isn't there. It's just relatively easy for a developer to work around since everything is, well, local, so we haven't been particularly strongly motivated to prioritize looking at it.

For the same reason, though, I don't think it would be particularly complicated to do. Overload resolution is complex, yes, but not more so here than elsewhere; in fact because there is no inheritance chain to consider it is probably a bit simpler.

For the top-level statements scenario, I agree that it feels different but I don't think it is different: Here as elsewhere, the local functions are only available to the immediately adjacent code. However: When we added top-level statements we were careful to protect the design space, so that top level local functions could later become full-fledged top level function declarations; ones that can have accessibility, live in namespaces and be imported by other assemblies. At that point it really is different, and the arguments for overloading become stronger - the functions can now be part of an API surface area.

All in all I probably feel that having overloading apply uniformly across the places in the language where functions/methods can be declared is probably "simpler" than special casing certain contexts like we do today. I'm just not convinced that it competes favorably against other things we currently have on the docket, priority-wise.

Finally, let me also add a "slippery slope" argument: Why stop at overloaded functions? Why not add local properties? Events? Indexers? Etc. What's a natural point to stop, and why?

[HaloFour]

There have been a couple of discussions on this repo from developers confused as to why they can't overload instance methods with local methods. Would that also be under consideration?

Finally, let me also add a "slippery slope" argument: Why stop at overloaded functions? Why not add local properties? Events? Indexers? Etc. What's a natural point to stop, and why?

I think local extension methods would be very welcome. Local types, too (although personally I'd prefer anonymous types that can implement interfaces).

[Kir-Antipov]

Finally, let me also add a "slippery slope" argument: Why stop at overloaded functions? Why not add local properties? Events? Indexers? Etc. What's a natural point to stop, and why?

A natural point to stop is the question "Does it make sense?" Do overloaded functions make sense? Yeah. Indexers and events? Nope, they only make sense when they are available for external use, when the object has state. On the other hand, sometimes methods actually have state (caching, precomputed data and so on), so local properties would make sense!

Sometimes I miss C++ static variables, 'cause it would be nice to be able to write something like this:

static Foo GetFoo(Bar bar)
{
    static Dictionary<Bar, Foo> cache = new();
    if (!cache.TryGetValue(bar, out Foo foo))
    {
        foo = ComputeFoo(bar);
        cache.Add(bar, foo);
    }
    return foo;
}

This thing serves the same purpose local functions do: encapsulates some logic, that only makes sense in terms of the given method. So, it would fit in nicely

[maxkoshevoi]

For the top-level statements scenario, I agree that it feels different but I don't think it is different

My main concern is about top level programs and people who are learning C# using them.
Also if top level program will become a default template in .Net 6 (dotnet/templating#3359), a lot more people will face this limitation.

top level local functions could later become full-fledged top level function declarations

This would actually solve the issue. Do you have any plans on implementing that?

[prlcutting]

This problem also extends to local functions and member functions:

public class Program
{
    static void Main(string[] args)
    {
        A("hi");
        A(42); // Argument 1: cannot convert from 'int' to 'string'

        void A(string s) { }
    }
	
    static void A(int i) { }
}

I find it's sometimes useful to have a local function delegate to a member function, and pass captured variables along. This reduces/simplifies the argument list for the caller of the local function. It's most useful when the same local function needs to be called many times. However, this can't be achieved with overloading as the following example shows, which requires introducing a contrived name for one of the functions when they represent the same concept.

public class Program
{
    static void Main(string[] args)
    {
	bool b = true;
        A("hi");

        void A(string s) => A(s, b); //No overload for method 'A' takes 2 arguments
    }
	
	static void A(string s, bool b) { }
}

[siegfriedpammer]

Program.A seems to be a perfectly fine workaround in this situation. I even think it is more readable.

[prlcutting]

That's true, if the method is static, as indeed my example was, but it but what if it's an instance member? That's the more typical use case for me.

[snarbies]

Then it can be qualified with this.

[prlcutting]

Of course. Well now I feel more than a little bit silly! 🤦‍♂️