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/

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/

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/

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/

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/

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/

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/

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/