www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - dmd v0.96: unittest block cannot see functions

reply Regan Heath <regan netwin.co.nz> writes:
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
parent reply J C Calvarese <jcc7 cox.net> writes:
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
next sibling parent reply Andrew <Andrew_member pathlink.com> writes:
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#nested



The 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
parent reply J C Calvarese <jcc7 cox.net> writes:
Andrew wrote:

 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#nested



 
 The spec goes on to say:
 
 |  "Future directions: This restriction may be removed."
 
 I think that, for consistency purposes, we should move towards that goal. 



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/
Jul 24 2004
parent reply Andrew <Andrew_member pathlink.com> writes:
In article <cdvds1$1lil$1 digitaldaemon.com>, J C Calvarese says...

Andrew wrote:

 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#nested



 
 The spec goes on to say:
 
 |  "Future directions: This restriction may be removed."
 
 I think that, for consistency purposes, we should move towards that goal. 



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.



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.


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
parent Regan Heath <regan netwin.co.nz> writes:
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...

 Andrew wrote:

 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#nested




 The spec goes on to say:

 |  "Future directions: This restriction may be removed."

 I think that, for consistency purposes, we should move towards that 
 goal.



 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.



 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.


 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/








-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jul 25 2004
prev sibling parent reply Regan Heath <regan netwin.co.nz> writes:
On Sat, 24 Jul 2004 22:56:23 -0500, J C Calvarese <jcc7 cox.net> wrote:

 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



Ah.. that explains it.


 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.



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
parent J C Calvarese <jcc7 cox.net> writes:
Regan Heath wrote:

 On Sat, 24 Jul 2004 22:56:23 -0500, J C Calvarese <jcc7 cox.net> wrote:
 

 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



 
 Ah.. that explains it.
 

 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.



 
 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?



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. :)


 

 "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.
 




-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/
Jul 25 2004