www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Const spec status.

reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
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
Apr 27 2008
next sibling parent reply "Janice Caron" <caron800 googlemail.com> writes:
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;

Apr 27 2008
parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
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
Apr 28 2008
parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
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
Apr 29 2008
prev sibling next sibling parent reply "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
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
Apr 27 2008
parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
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
Apr 28 2008
prev sibling next sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Bruno Medeiros wrote:
 Somewhere during the const discussions, I fired up Eclipse (shameless 
 publicity)

Descent's parser isn't D2-ready yet.
Apr 28 2008
parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
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
Apr 28 2008
prev sibling parent "Janice Caron" <caron800 googlemail.com> writes:
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.
Apr 28 2008