• Bruno Medeiros <brunodomedeiros+spam com.gmail> Apr 27 2008
• "Janice Caron" <caron800 googlemail.com> Apr 27 2008
• Bruno Medeiros <brunodomedeiros+spam com.gmail> Apr 28 2008
• Bruno Medeiros <brunodomedeiros+spam com.gmail> Apr 29 2008
• "Simen Kjaeraas" <simen.kjaras gmail.com> Apr 27 2008
• Bruno Medeiros <brunodomedeiros+spam com.gmail> Apr 28 2008
• Robert Fraser <fraserofthenight gmail.com> Apr 28 2008
• Bruno Medeiros <brunodomedeiros+spam com.gmail> Apr 28 2008
• "Janice Caron" <caron800 googlemail.com> Apr 28 2008

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



         int a = inv_num;



         invariant(int) b = num;




         const(int)[] c = inv_intArray;



         int[] d = inv_intArray;



         Object e = inv_object;



         Struct f = inv_Struct;

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


 
         int a = inv_num;


 
         invariant(int) b = num;


 
 
         const(int)[] c = inv_intArray;


 
         int[] d = inv_intArray;


 
         Object e = inv_object;


 
         Struct f = inv_Struct;




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

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

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

 module test;

 import std.stdio;


 struct Struct {
 	int x;
 }

 void main()
 {

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


 	/** 6 Const cases **/

 	// Case 1
 	int a =3D inv_num;


Works. inv_num is a POD type.

 	// Case 2
 	invariant(int) b =3D num;


Works. See above.

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


Works. invariant is implicitly castable to const.

 	// Case 4
 	int[] d =3D inv_intArray;


Does not work.

 	// Case 5
 	Object e =3D inv_object;


Does not work.

 	// Case 6
 	Struct f =3D 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 =3D { &baz }; // this works. I'd believe it is a bug.

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


-- Simen

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

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


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

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.