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