3492 – Can't overload nested functions

Nested functions don't overload like non-nested functions. If this behavior is correct, it seems like a fairly arbitrary limitation, but it should be clarified in the spec.
void main() {
 static void foo(uint a, float b) {}
 static void foo(float a, uint b) {}
}
Error: declaration foo is already defined

Commit pushed to https://github.com/D-Programming-Language/d-programming-language.org
https://github.com/D-Programming-Language/d-programming-language.org/commit/5d98834d711cebd4d218a0580856b84de6dcb10f
fix Issue 3492 - Can't overload nested functions

Nested functions are a great feature, especially when experimenting with code and when I need to do some quick filtering over e.g. hashes but need to access some outer state. With nested functions I don't have to use global variables or use ref parameters (I'm talking about non-static functions).
I've just tried using overloaded functions but failed and found this in bugzilla. It's not a big issue, I can rename the functions.. but I'd like to know the rationale for this limitation.

The reason is straightforward - there's no point to it. Nested functions tend to be right next to where they are used. They're not off in a separate file.
We shouldn't have features just to have features. They have to have an identifiable benefit. Overloaded functions introduce complexity both to the user and the compiler - and there is no clear benefit for nested functions.

The reason is straightforward - there's no point to it. Nested functions tend to be right next to where they are used. They're not off in a separate file.
We shouldn't have features just to have features. They have to have an identifiable benefit. Overloaded functions introduce complexity both to the user and the compiler - and there is no clear benefit for nested functions.

Really? I'm constantly annoyed by that you can't overload nested functions when writing unit tests. I frequently need to overload functions in unittest blocks and have to play games to get around the fact that I can't. The worst is when you use foreach and TypeTuple. You can't just do something like
foreach(T; TypeTuple!(string, wstring, dstring))
{
 void test(T actual, T expected, ...)
 {
 }
 test(...);
 test(...);
 test(...);
 ...
}
because then every subsequent definition of the nested function conflicts with the rest. You're force to use string mixins simply to give each overload of the nested function a unique name. It's an extra complication that really shouldn't be necessary IMHO.
If anything, I'd argue that the lack of ability to overload nested functions is an unnecassary inconsistency in the language.

(In reply to comment #4)
> The reason is straightforward - there's no point to it. Nested functions tend
> to be right next to where they are used. They're not off in a separate file.
> 
> We shouldn't have features just to have features.
But we do have overloading in the language already. We shouldn't just deny access to existing features. Chances are that a compiler works better if there are no arbitrary inconsistencies (see all the bugs related to parsing storage classes of nested declarations for an example -- just define the language such that reusing parsing procedures is easy.)
> They have to have an identifiable benefit. Overloaded functions introduce complexity both to the user and the compiler - and there is no clear benefit for nested functions.
What introduces complexity to the user and the compiler is that the syntax (and, like in this case, even the semantics!) of function local declarations is substantially different from global declarations and declarations inside aggregates. It is not 'turtles all the way down', it is not consistent, and it is not useful. Those are arbitrary limitations. I'd suspect that DMD can even handle correctly most of the function local features that are currently invalid syntax.

>because then every subsequent definition of the nested function conflicts with
the rest.
You can make test() a template function.