www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Inner function overload bug?

reply "Era Scarecrow" <rtcvb32 yahoo.com> writes:
  Hmmm...  Curious case, I think it's a bug; Depends on if inner 
functions qualify for overloading or not.

   //globally or in struct/class/union works fine
   int test() {return 0;}
   void test(int x) {}

   unittest {
     int test() {return 0;}
     void test(int x) {} //test already defined
   }

   void func() {
     int test() {return 0;}
     void test(int x) {} //test already defined

     static int test2() {return 0;}
     static void test2(int x) {}  //test2 already defined
   }
Jan 08 2013
parent reply Philippe Sigaud <philippe.sigaud gmail.com> writes:
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.
Jan 08 2013
next sibling parent reply "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Tuesday, 8 January 2013 at 21:12:34 UTC, 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.
Hmm I seemed to have missed that. 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.
Jan 08 2013
next sibling parent reply Philippe Sigaud <philippe.sigaud gmail.com> writes:
On Tue, Jan 8, 2013 at 10:43 PM, Era Scarecrow <rtcvb32 yahoo.com> wrote:
  Hmm I seemed to have missed that.

  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.
I had a bunch of troubles trying to define nested functions automatically generated. The fact that they cannot be recursive killed the deal for me (that was for a parser, which needs recursion).
Jan 08 2013
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Philippe Sigaud:

 I had a bunch of troubles trying to define nested functions
 automatically generated. The fact that they cannot be recursive 
 killed
 the deal for me (that was for a parser, which needs recursion).
If you define an inner static struct, its static methods can call each other freely. Bye, bearophile
Jan 08 2013
next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 1/9/13, bearophile <bearophileHUGS lycos.com> wrote:
 If you define an inner static struct, its static methods can call
 each other freely.
You can also use a mixin template: mixin template S() { void test(ref int x) { x = test(); } int test() { return 1; } } void main() { mixin S; int x; test(x); assert(x == 1); }
Jan 08 2013
parent "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Wednesday, 9 January 2013 at 00:53:16 UTC, Andrej Mitrovic 
wrote:
 mixin template S()
 {
     void test(ref int x) { x = test(); }
     int test() { return 1; }
 }

 void main()
 {
     mixin S;

     int x;
     test(x);
     assert(x == 1);
 }
An interesting idea, but the more obvious uses it would be for is bitfields or something similar, which is generated text and mixed in. Would you do a mixin within a mixin template to get that to work? I'd rather just mixin directly to the function. //works with above main? mixin template S() { mixin(bitfields!( int, "test", 8, )); }
Jan 08 2013
prev sibling parent reply Philippe Sigaud <philippe.sigaud gmail.com> writes:
On Wed, Jan 9, 2013 at 1:53 AM, Andrej Mitrovic
<andrej.mitrovich gmail.com> wrote:
 On 1/9/13, bearophile <bearophileHUGS lycos.com> wrote:
 If you define an inner static struct, its static methods can call
 each other freely.
You can also use a mixin template: mixin template S() { void test(ref int x) { x = test(); } int test() { return 1; } } void main() { mixin S; int x; test(x); assert(x == 1); }
That's weird. Why does that work? Directly pasting the mixin content in main() does not compile, right?
Jan 09 2013
parent reply "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Wednesday, 9 January 2013 at 10:53:53 UTC, Philippe Sigaud 
wrote:
 On Wed, Jan 9, 2013 at 1:53 AM, Andrej Mitrovic wrote:
 On 1/9/13, bearophile wrote:
 If you define an inner static struct, its static methods can 
 call each other freely.
You can also use a mixin template: mixin template S() { void test(ref int x) { x = test(); } int test() { return 1; } } void main() { mixin S; int x; test(x); assert(x == 1); }
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. Overloading within nested functions is likely a rare use case.
Jan 09 2013
parent reply Philippe Sigaud <philippe.sigaud gmail.com> writes:
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.
Jan 09 2013
parent dennis luehring <dl.soluz gmx.net> writes:
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
Jan 09 2013
prev sibling parent reply dennis luehring <dl.soluz gmx.net> writes:
Am 08.01.2013 22:43, schrieb Era Scarecrow:
 On Tuesday, 8 January 2013 at 21:12:34 UTC, 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.
Hmm I seemed to have missed that. 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?
Jan 09 2013
parent "Era Scarecrow" <rtcvb32 yahoo.com> writes:
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.
Jan 09 2013
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
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.
Jan 10 2013
next sibling parent "Era Scarecrow" <rtcvb32 yahoo.com> writes:
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.
Jan 10 2013
prev sibling parent Brad Roberts <braddr puremagic.com> writes:
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.
Jan 10 2013