digitalmars.D.bugs - dmd v0.96: unittest block cannot see functions
- Regan Heath (35/35) Jul 24 2004 This fails to compile:
- J C Calvarese (28/47) Jul 24 2004 I can see why you'd want this to work, but according to the
- Andrew (4/10) Jul 24 2004 The spec goes on to say:
- J C Calvarese (10/23) Jul 24 2004 I'm in favor of removing the restriction. But I would call it a
- Andrew (3/26) Jul 25 2004 Agreed! This is not a bug. Only wanted to say that it was still worth pu...
- Regan Heath (11/42) Jul 25 2004 Andrew/JC,
- Regan Heath (11/55) Jul 25 2004 It would be nice if they didn't have to be declared first. I assume this...
- J C Calvarese (6/80) Jul 25 2004 I'm sure it takes more effort for the person writing the compiler. Maybe...
This fails to compile: unittest { try { writeFile(); //undefined identifier writeFile readFile(); } catch(Exception e) { e.print(); } void writeFile() { } void readFile() { } } This works: unittest { void writeFile() { } void readFile() { } try { writeFile(); readFile(); } catch(Exception e) { e.print(); } } Regan -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jul 24 2004
Regan Heath wrote:This fails to compile: unittest { try { writeFile(); //undefined identifier writeFile readFile(); } catch(Exception e) { e.print(); } void writeFile() { } void readFile() { } }I can see why you'd want this to work, but according to the specification, it won't. Basically, a unittest block is a "special member function". http://www.digitalmars.com/d/class.html So these functions that you're declaring in the unittest are actually nested functions. But nested functions have to be declared before they're used. "Unlike module level declarations, declarations within function scope are processed in order." http://www.digitalmars.com/d/function.html#nested Thus, this doesn't work: void main() { fn1(); void fn1() {} } Error: main.d(3): undefined identifier fn1 Of course, this works fine: void main() { void fn1() {} fn1(); } -- Justin (a/k/a jcc7) http://jcc_7.tripod.com/d/
Jul 24 2004
In article <cdvb18$1jb6$3 digitaldaemon.com>, J C Calvarese says..."Unlike module level declarations, declarations within function scope are processed in order." http://www.digitalmars.com/d/function.html#nestedThe spec goes on to say: | "Future directions: This restriction may be removed." I think that, for consistency purposes, we should move towards that goal.-- Justin (a/k/a jcc7) http://jcc_7.tripod.com/d/
Jul 24 2004
Andrew wrote:In article <cdvb18$1jb6$3 digitaldaemon.com>, J C Calvarese says...I'm in favor of removing the restriction. But I would call it a "documented limitation" rather than a bug. If I wanted to discuss the known limitations of D, I'd post in the main newsgroup. If DMD is following the spec, I don't see it as a bug. But that's just my opinion. And I thought I'd let the OP know that the spec seems to back up the behavior. -- Justin (a/k/a jcc7) http://jcc_7.tripod.com/d/"Unlike module level declarations, declarations within function scope are processed in order." http://www.digitalmars.com/d/function.html#nestedThe spec goes on to say: | "Future directions: This restriction may be removed." I think that, for consistency purposes, we should move towards that goal.
Jul 24 2004
In article <cdvds1$1lil$1 digitaldaemon.com>, J C Calvarese says...Andrew wrote:Agreed! This is not a bug. Only wanted to say that it was still worth pursuing. But you are right: The correct battlefield is the main NG.In article <cdvb18$1jb6$3 digitaldaemon.com>, J C Calvarese says...I'm in favor of removing the restriction. But I would call it a "documented limitation" rather than a bug. If I wanted to discuss the known limitations of D, I'd post in the main newsgroup. If DMD is following the spec, I don't see it as a bug. But that's just my opinion."Unlike module level declarations, declarations within function scope are processed in order." http://www.digitalmars.com/d/function.html#nestedThe spec goes on to say: | "Future directions: This restriction may be removed." I think that, for consistency purposes, we should move towards that goal.And I thought I'd let the OP know that the spec seems to back up the behavior. -- Justin (a/k/a jcc7) http://jcc_7.tripod.com/d/
Jul 25 2004
Andrew/JC, My first mistake was not realising unittest was a function, if I had I'd have realised they were nested functions, if I had I wouldn't have posted to the bugs group :). JC: thanks for a complete explaination, I _might_ have needed it (I didn't in this case, as soon as you said unittest was a fn...) :) Regan On Sun, 25 Jul 2004 09:05:06 +0000 (UTC), Andrew <Andrew_member pathlink.com> wrote:In article <cdvds1$1lil$1 digitaldaemon.com>, J C Calvarese says...-- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/Andrew wrote:Agreed! This is not a bug. Only wanted to say that it was still worth pursuing. But you are right: The correct battlefield is the main NG.In article <cdvb18$1jb6$3 digitaldaemon.com>, J C Calvarese says...I'm in favor of removing the restriction. But I would call it a "documented limitation" rather than a bug. If I wanted to discuss the known limitations of D, I'd post in the main newsgroup. If DMD is following the spec, I don't see it as a bug. But that's just my opinion."Unlike module level declarations, declarations within function scope are processed in order." http://www.digitalmars.com/d/function.html#nestedThe spec goes on to say: | "Future directions: This restriction may be removed." I think that, for consistency purposes, we should move towards that goal.And I thought I'd let the OP know that the spec seems to back up the behavior. -- Justin (a/k/a jcc7) http://jcc_7.tripod.com/d/
Jul 25 2004
On Sat, 24 Jul 2004 22:56:23 -0500, J C Calvarese <jcc7 cox.net> wrote:Regan Heath wrote:Ah.. that explains it.This fails to compile: unittest { try { writeFile(); //undefined identifier writeFile readFile(); } catch(Exception e) { e.print(); } void writeFile() { } void readFile() { } }I can see why you'd want this to work, but according to the specification, it won't. Basically, a unittest block is a "special member function". http://www.digitalmars.com/d/class.htmlSo these functions that you're declaring in the unittest are actually nested functions. But nested functions have to be declared before they're used.It would be nice if they didn't have to be declared first. I assume this is either a lot of work or just plain impossible?"Unlike module level declarations, declarations within function scope are processed in order." http://www.digitalmars.com/d/function.html#nested Thus, this doesn't work: void main() { fn1(); void fn1() {} } Error: main.d(3): undefined identifier fn1 Of course, this works fine: void main() { void fn1() {} fn1(); }Thanks for the explaination. I kinda suspected it wasn't a bug, but I did not know why it wasn't working the way I wanted it to. I haven't used nested functions at all yet, if I had, I'd have probably realised what was going on. :) Regan. -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jul 25 2004
Regan Heath wrote:On Sat, 24 Jul 2004 22:56:23 -0500, J C Calvarese <jcc7 cox.net> wrote:I'm sure it takes more effort for the person writing the compiler. Maybe if we're lucky it'll be in D 2.0. :)Regan Heath wrote:Ah.. that explains it.This fails to compile: unittest { try { writeFile(); //undefined identifier writeFile readFile(); } catch(Exception e) { e.print(); } void writeFile() { } void readFile() { } }I can see why you'd want this to work, but according to the specification, it won't. Basically, a unittest block is a "special member function". http://www.digitalmars.com/d/class.htmlSo these functions that you're declaring in the unittest are actually nested functions. But nested functions have to be declared before they're used.It would be nice if they didn't have to be declared first. I assume this is either a lot of work or just plain impossible?-- Justin (a/k/a jcc7) http://jcc_7.tripod.com/d/"Unlike module level declarations, declarations within function scope are processed in order." http://www.digitalmars.com/d/function.html#nested Thus, this doesn't work: void main() { fn1(); void fn1() {} } Error: main.d(3): undefined identifier fn1 Of course, this works fine: void main() { void fn1() {} fn1(); }Thanks for the explaination. I kinda suspected it wasn't a bug, but I did not know why it wasn't working the way I wanted it to. I haven't used nested functions at all yet, if I had, I'd have probably realised what was going on. :) Regan.
Jul 25 2004