www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - Const block within function refuses to compile

reply Deewiant <deewiant.doesnotlike.spam gmail.com> writes:
It appears that using a const block within a function does not work and
causes the compiler to throw up. The problem is the same as here:
http://www.digitalmars.com/d/archives/digitalmars/D/19653.html

And it still isn't fixed (DMD 0.127, Windows). Minimal test case with a
few examples:


 class A {
 	private const { int a; } // works
 }
 
 const { int b; } // works
 
 void main() {
 	const {	int c; } // doesn't work
 }


The line in main() gives me:

asdf.d(8): basic type expected, not {
asdf.d(8): no identifier for declarator int
asdf.d(8): semicolon expected, not '{'

If I remove the curly brackets it compiles fine. I can't think of a
reason why it shouldn't work with them included.

--

As a side note, regarding const arrays this time, the following code:


 import std.stdio;
 void main() {
 	const char[] foo = "bar";
 	foo[1] = 'Z';
 	writefln(foo);
 }


Compiles and runs fine, and prints 'bar'. IMHO one of the following
should happen:
	a) Const arrays are fully const, and compiler whines about trying to
assign to a const array,
	b) Const arrays' elements are not const, and 'bZr' is printed,
	c) Const arrays' elements are fully const, and the compiler gives a
warning about the statement being ignored.

The last one I consider least likely to be 'correct', since D isn't
meant to have warnings. Personally I would prefer the first to happen,
but b) would be fine as well (and seems most likely -
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/3445).
What is currently happening just doesn't seem at all correct.
Jun 21 2005
next sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Deewiant wrote:

 It appears that using a const block within a function does not work and
 causes the compiler to throw up. The problem is the same as here:
 http://www.digitalmars.com/d/archives/digitalmars/D/19653.html


The only "problem" is that somebody didn't read the spec accurately. 
The code snippet copied there is not within a function.

<snip>

 If I remove the curly brackets it compiles fine. I can't think of a
 reason why it shouldn't work with them included.


<snip>

The attribute block syntax applies only at module or class/struct/union 
level, not at function level.

They couldn't do it with synchronized, since there would be then two 
meanings of synchronized { ... } at function level and it would be 
difficult to disambiguate them.

Even so, maybe there isn't really a reason that you shouldn't still be 
able to do it with const or others.  But it would appear that the D 
grammar ended up treating all attributes as equal in this respect, and 
therefore not allowing this to be done with const in a function either.

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on 
the 'group where everyone may benefit.
Jun 21 2005
prev sibling parent "Regan Heath" <regan netwin.co.nz> writes:
On Tue, 21 Jun 2005 15:31:20 +0300, Deewiant  
<deewiant.doesnotlike.spam gmail.com> wrote:

 As a side note, regarding const arrays this time, the following code:


 import std.stdio;
 void main() {
 	const char[] foo = "bar";
 	foo[1] = 'Z';
 	writefln(foo);
 }


 Compiles and runs fine, and prints 'bar'.


It seems this has changed. 'const' applied to an array used to only effect  
the 'array reference' itself, not the data to which it reffered. As shown  
in your link below. I must have missed the changelog entry for this change.


 IMHO one of the following
 should happen:
 	a) Const arrays are fully const, and compiler whines about trying to
 assign to a const array,


If by 'whines' you mean, gives an error then my vote goes to this option.


 	b) Const arrays' elements are not const, and 'bZr' is printed,


This is the old behaviour IIRC.


 	c) Const arrays' elements are fully const, and the compiler gives a
 warning about the statement being ignored.


As you say, D does not have warnings (except it does, with the -w option).


 The last one I consider least likely to be 'correct', since D isn't
 meant to have warnings. Personally I would prefer the first to happen,
 but b) would be fine as well (and seems most likely -
 http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/3445).
 What is currently happening just doesn't seem at all correct.


Well.. it's halfway there, the data appears to be constant now. The next  
step is detecting and erroring on an assignment to const data and/or  
simply crashing/throwing when it's done.

Regan
Jun 21 2005