On Wednesday, 9 January 2013 at 12:03:30 UTC, dennis luehring wrote:
> Am 08.01.2013 22:43, schrieb Era Scarecrow:
>> That just means my unittest wouldn't work, so either it has to be global or inside a struct/union/class (and global is not very likely).
>>
>>   Thanks for clearing that up.
>>
>
> isn't that some sort of hijacking then?

 Not sure how you mean, and I'm not sure how you would hi-Jack it. It's a nested function, and shares no names with anything else, private to the unittest; But the requirement to put it inside a struct although semi-restrictive isn't enough of an issue to rant about. Nested functions would probably be for recursive or helper functions (lambdas?) and wouldn't need overloading anyways.

On Wed, Jan 9, 2013 at 12:52 PM, Era Scarecrow <rtcvb32@yahoo.com> wrote:

>> That's weird. Why does that work? Directly pasting the mixin content in main() does not compile, right?
>
>  I can only assume if it does work, that the mixin template has it's own
> scope that enables the overloading. If you can't do it with one, you
> shouldn't be allowed to do it with the other.

That must be it. mixin can have names (mixin TemplateName AliasName;)
which the functions as a disambiguator.
I don't have access to a D compiler right now. Does this work?:


void main()
{
    {
        void test(ref int x) { x = test(); }
        int test() { return 1; }
    }
    int x;
    test(x);
    assert(x == 1);
}



>  Overloading within nested functions is likely a rare use case.

I hit it while trying to change a module from struct+methods to purely functions everywhere, to see if there were any efficiency difference.

Am 09.01.2013 14:21, schrieb Philippe Sigaud:
> On Wed, Jan 9, 2013 at 12:52 PM, Era Scarecrow <rtcvb32@yahoo.com> wrote:
>
>>> That's weird. Why does that work? Directly pasting the mixin content in
>>> main() does not compile, right?
>>
>>  I can only assume if it does work, that the mixin template has it's own
>> scope that enables the overloading. If you can't do it with one, you
>> shouldn't be allowed to do it with the other.
>
> That must be it. mixin can have names (mixin TemplateName AliasName;)
> which the functions as a disambiguator.
> I don't have access to a D compiler right now. Does this work?:
>
>
> void main()
> {
>      {
>          void test(ref int x) { x = test(); }
>          int test() { return 1; }
>      }
>      int x;
>      test(x);
>      assert(x == 1);
> }
>
>
>
>>  Overloading within nested functions is likely a rare use case.
>
> I hit it while trying to change a module from struct+methods to purely
> functions everywhere, to see if there were any efficiency difference.
>

http://dpaste.dzfl.pl/ ist your friend

Compilation output:
/home/c250/c278.d(4): Error: function c278.main.test (ref int x) is not callable using argument types ()
/home/c250/c278.d(4): Error: expected 1 function arguments, not 0
/home/c250/c278.d(5): Error: declaration test is already defined
/home/c250/c278.d(8): Error: undefined identifier test

On 01/08/2013 10:12 PM, Philippe Sigaud wrote:
> It's conform to the spec
>
> http://dlang.org/function.html
>
> Last line of the 'nested functions' subsection:
>
> "Nested functions cannot be overloaded."
> Nested functions cannot be overloaded.

Note that this is a case of the spec being adapted to the implementation. It has been added after I complained about the DMD behaviour.

On Friday, 11 January 2013 at 01:49:03 UTC, Timon Gehr wrote:
> On 01/08/2013 10:12 PM, Philippe Sigaud wrote:
>> "Nested functions cannot be overloaded."
>
> Note that this is a case of the spec being adapted to the implementation. It has been added after I complained about the DMD behaviour.

 So it's just clarification to be correct because the frontend does it? Doesn't seem quite right... It breaks a certain level of consistency; Although need for such overloading is likely close to nil anyways.

On 1/10/2013 5:49 PM, Timon Gehr wrote:
> On 01/08/2013 10:12 PM, Philippe Sigaud wrote:
>> It's conform to the spec
>>
>> http://dlang.org/function.html
>>
>> Last line of the 'nested functions' subsection:
>>
>> "Nested functions cannot be overloaded."
>> Nested functions cannot be overloaded.
> 
> Note that this is a case of the spec being adapted to the implementation. It has been added after I complained about the DMD behaviour.

Careful with that sort of logic.  Just because the spec was updated such that it matches the implementation does NOT mean that it was because that just happens to be the implementation.  It's also likely that it was _intentional_ and had the spec been written first it would have been done the same way.

If you want to propose changing the behavior, do that, but don't attempt to blame the implementation as the reason for the spec.