This post is *not* another const proposal.

I want to know if something changed with the const system. You see:

Somewhere during the const discussions, I fired up Eclipse (shameless publicity) and started testing various code samples around const/invariant. This was around const version 3, however, most of the code samples I tried didn't work as I expected. It wasn't that I didn't grok const, it just seemed the spec had changed somewhat. (and it wasn't bug fixes either, as I was following those around, at least the publicly know ones, so I would recognized them)
It was if we were now in a version 4 of const (I say version 4 because this "new" version seem much better than 3). But I checked the spec:
http://www.digitalmars.com/d/2.0/const3.html
and nothing had changed. Everything seemed to be according to the spec. So now I got confused. Maybe Walter's comments in the NG put me offtrack?

To test this theory, *and has an interesting exercise on itself*, I ask any participant in the NG who thinks they have a fair understanding of const, to consider these simple 6 cases of const usage:

----  ----
module test;

import std.stdio;


struct Struct {
	int x;
}

void main()
{

	// helper objects
	int num = 10;
	invariant(int) inv_num = 1;
	invariant(int[]) inv_intArray = [1, 2];
	invariant(Object) inv_object = cast(invariant) new Object();
	invariant Struct inv_Struct = { 1 };


	/** 6 Const cases **/

	// Case 1
	int a = inv_num;
	
	// Case 2
	invariant(int) b = num;

	// Case 3
	const(int)[] c = inv_intArray;

	// Case 4
	int[] d = inv_intArray;
	
	// Case 5
	Object e = inv_object;
	
	// Case 6
	Struct f = inv_Struct;
	
}

----  ----

and tell which ones you think are valid and which are not. Before running them through the compiler of course! (or checking other's answers) Just look at the current documentation (http://www.digitalmars.com/d/2.0/const3.html), and/or what has been said in the newsgroups, to try to figure it out. Also, nothing of this has changed with 2.013, it worked the same with at least 2.012.

I think we may see some interesting results.

Also, with the answers to code cases above, one can quickly construct a case that (yet again) actually *breaks* the const system.

-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

On 27/04/2008, Bruno Medeiros <brunodomedeiros+spam@com.gmail> wrote:
>  and tell which ones you think are valid and which are not. Before running
Here goes:

>         int a = inv_num;
OK

>         invariant(int) b = num;
OK


>         const(int)[] c = inv_intArray;
OK

>         int[] d = inv_intArray;
ERROR

>         Object e = inv_object;
ERROR

>         Struct f = inv_Struct;
OK

Bruno Medeiros <brunodomedeiros+spam@com.gmail> wrote:

> module test;
>
> import std.stdio;
>
>
> struct Struct {
> 	int x;
> }
>
> void main()
> {
>
> 	// helper objects
> 	int num = 10;
> 	invariant(int) inv_num = 1;
> 	invariant(int[]) inv_intArray = [1, 2];
> 	invariant(Object) inv_object = cast(invariant) new Object();
> 	invariant Struct inv_Struct = { 1 };
>
>
> 	/** 6 Const cases **/
>
> 	// Case 1
> 	int a = inv_num;

Works. inv_num is a POD type.

> 	// Case 2
> 	invariant(int) b = num;

Works. See above.

> 	// Case 3
> 	const(int)[] c = inv_intArray;

Works. invariant is implicitly castable to const.

> 	// Case 4
> 	int[] d = inv_intArray;

Does not work.

> 	// Case 5
> 	Object e = inv_object;

Does not work.

> 	// Case 6
> 	Struct f = inv_Struct;

Works. Struct is POD.

> }


Interesting thing I found (because I was unsure of the Struct):


struct foo
{
	int* bar;
}


int baz;

invariant foo f = { &baz }; // this works. I'd believe it is a bug.

foo g = f; // also works. Might be even worse.


-- Simen

Bruno Medeiros wrote:
> Somewhere during the const discussions, I fired up Eclipse (shameless publicity)

Descent's parser isn't D2-ready yet.

Janice Caron wrote:
> On 27/04/2008, Bruno Medeiros <brunodomedeiros+spam@com.gmail> wrote:
>>  and tell which ones you think are valid and which are not. Before running
> Here goes:
> 
>>         int a = inv_num;
> OK
> 
>>         invariant(int) b = num;
> OK
> 
> 
>>         const(int)[] c = inv_intArray;
> OK
> 
>>         int[] d = inv_intArray;
> ERROR
> 
>>         Object e = inv_object;
> ERROR
> 
>>         Struct f = inv_Struct;
> OK

Both you and Simen got it right.
Hum, I feel a bit silly, I originally thought that *all* cases would be an error, so maybe it was just I that got confused with a previous version of const. (where values could only be assigned to variables with the same "head-constness", which is not the case here)

-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Simen Kjaeraas wrote:
> 
> 
> Interesting thing I found (because I was unsure of the Struct):
> 
> 
> struct foo
> {
>     int* bar;
> }
> 
> 
> int baz;
> 
> invariant foo f = { &baz }; // this works. I'd believe it is a bug.
> 
> foo g = f; // also works. Might be even worse.
> 
> 
> -- Simen

Yes, that's pretty much the bug I mentioned in the original post (the "case that (yet again) actually *breaks* the const system").
Bug reported.


-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Robert Fraser wrote:
> Bruno Medeiros wrote:
>> Somewhere during the const discussions, I fired up Eclipse (shameless publicity)
> 
> Descent's parser isn't D2-ready yet.

I wasn't using Descent, but Mmrnmhrm. :)

And Descent's parser does have some support for D2, since Mmrnmhrm uses  Descent's parser, and it understands some of the earlier versions of D2.
And if you configure Descent to the 2.x language level, it also works fine, at least with const/invariant syntax. Where you thinking of something else?

-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

2008/4/29 Bruno Medeiros <brunodomedeiros+spam@com.gmail>:
>  Hum, I feel a bit silly, I originally thought that *all* cases would be an
> error, so maybe it was just I that got confused with a previous version of
> const. (where values could only be assigned to variables with the same
> "head-constness", which is not the case here)

The definition of const hasn't changed. (At least, not recently). It's just that bugs have been fixed. The compiler is now better at figuring out what is safe and what is not.

There are still one or two bugs remaining, but as time goes by, we'll see those fixed too. We have a good system here.

Janice Caron wrote:
> 2008/4/29 Bruno Medeiros <brunodomedeiros+spam@com.gmail>:
>>  Hum, I feel a bit silly, I originally thought that *all* cases would be an
>> error, so maybe it was just I that got confused with a previous version of
>> const. (where values could only be assigned to variables with the same
>> "head-constness", which is not the case here)
> 
> The definition of const hasn't changed. (At least, not recently). It's
> just that bugs have been fixed. The compiler is now better at figuring
> out what is safe and what is not.
> 

I had the impression that this code:
  invariant a = 2;
  int b = a;
was at some point either not working, or written in the doc as not working. But that doesn't matter anymore, I agree what we have now is good (at least the basic semantics) , so let's move on. :)

-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D