Allow local function overloading

[dlangBugzillaToGithub]

monarchdodra reported this on 2014-04-14T10:56:01Z

Transferred from https://issues.dlang.org/show_bug.cgi?id=12578

CC List

• Walter Bright (@WalterBright)
• Jonathan M Davis (@jmdavis)
• Mithun Hunsur
• Victor Porton
• Simen Kjaeraas

Description

From the conversation:
http://forum.dlang.org/thread/gxzqflbxjmlewdsfwykt@forum.dlang.org

Basically, this fails:
//----
void main()
{
    void foo();
    void foo(int);
}
//----
Error: declaration foo is already defined
//----

I *think* this is according to spec? However, I find this behavior unrational, since you can get it to work with a simple wrap:

//----
void main()
{
    static struct S
    {
        static void foo();
        static void foo(int);
    }
    alias foo = S.foo;
}
//----
Fine! No problem!
//----

Given that the second example compiles, I think the D language should allow local function overloading.

...

Or, if the issue is one of scope/context/forwardreferences (?) to at least allow overloading of static local functions, eg:

//----
void main()
{
    static void foo();
    static void foo(int);
}
//----

[dlangBugzillaToGithub]

monarchdodra commented on 2014-04-14T11:20:28Z

Also relevant: The declaration of nested structs/classes:
https://github.com/D-Programming-Language/phobos/pull/2074/files

[dlangBugzillaToGithub]

issues.dlang (@jmdavis) commented on 2014-04-14T12:25:00Z

It would also be in line with the "turtles all the way down" approach that we tend to favor to have nested functions be overloadable just like non-nested functions can be. The fact that nested functions can't be overloaded is inconsistent with functions in the rest of the language.

[dlangBugzillaToGithub]

bugzilla (@WalterBright) commented on 2014-04-15T07:00:07Z

The reasons for this behavior are twofold:

1. Local functions aren't visible outside of their scope. Their use is pretty limited, and so there isn't much of any benefit to overloadability.

2. Forward references aren't allowed in local scope, meaning any use of overloading would be fairly restricted anyway.

It's not impossible to overcome this, it just seems pointless.

[dlangBugzillaToGithub]

issues.dlang (@jmdavis) commented on 2014-04-15T08:59:41Z

I frequently need helper functions in unittest blocks, and the lack of ability to overload them can be quite annoying. So, in my experience, the lack of visibility outside of the local scope hasn't really stopped the need for overloading - rather the lack of overloading just ends up forcing you to move the nested functions into an outer scope where they don't belong in order to get the overloading to work. And while there may be cases where forward references might be needed, I don't recall any cases where that's been a problem for me.

[dlangBugzillaToGithub]

k.hara.pg commented on 2014-04-15T10:01:01Z

(In reply to Walter Bright from comment #3)
> 2. Forward references aren't allowed in local scope, meaning any use of
> overloading would be fairly restricted anyway.

By adding following rule for function local declarations, we can relax the restriction.

- If no runtime statements exist between two local declarations,
  compiler will declare them in one DeclDef scope.

Examples:
----

void main() {
  //{
    void foo()
    void foo(int) {}
    // These are declared in one DeclDef scope, so they can be overloaded each other.
  //}
}

The rule will work on general case.

void main() {
    struct S {
        int foo() { bar(); }
        static assert(x == 10);
    }
    void bar() { S s; }

    enum x = 10;

    // Declaraing S, bar, and x have no runtime side effect,
    // so they can be referred to each other.
}

If same name function declarations are divided to multiple DeclDefs, they cannot be overloaded.

void main() {
    void foo()
    void foo(int) {}
    // foo == overloaded function
    // --> ok

    int x;  // runtime statement divides DeclDefs

    void foo(string) {}
    // Another declaration of foo will conflict with the overloaded foo.
    // --> error
}

[dlangBugzillaToGithub]

me commented on 2014-04-15T12:38:06Z

My use-case for this was implementing a toString function for different types in my view template (i.e. embedded D in a display layout) code. Without it, I had to name each variant of the function something unique, which led to function names like toStringSerializeNode(serializeNode) and toStringDeserializeNode(deserializeNode) before I switched to the suggested static struct solution.

As was mentioned, this would also be helpful in unit tests and other areas in which helper functions for multiple types would be convenient. I personally believe it's incongruous to not support overloading in local scope; D treats local functions similarly to global functions in all the cases I've encountered, but this seems like one case where the behaviour doesn't match up.

[dlangBugzillaToGithub]

k.hara.pg commented on 2014-04-23T12:15:41Z

One more issue which has same root is a mutual call of local functions.

void test() {
  void foo() { bar(); } // error, bar not defined
  void bar() { foo(); } // ok
}

My proposal in comment#5 could resolve the case with same way.

[dlangBugzillaToGithub]

simen.kjaras commented on 2019-09-19T11:14:10Z

An example of how this limitation has consequences outside of simple nested functions is available in issue 20226, where selectively imported functions with identical names aren't callable due to this issue.

[dlangBugzillaToGithub]

simen.kjaras commented on 2020-08-04T07:50:48Z

*** Issue 21107 has been marked as a duplicate of this issue. ***