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.

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.

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