digitalmars.D - Const spec status.
- Bruno Medeiros (62/62) Apr 27 2008 This post is *not* another const proposal.
- Janice Caron (8/15) Apr 27 2008 OK
- Bruno Medeiros (9/31) Apr 28 2008 Both you and Simen got it right.
- Janice Caron (6/10) Apr 28 2008 The definition of const hasn't changed. (At least, not recently). It's
- Bruno Medeiros (10/20) Apr 29 2008 I had the impression that this code:
- Simen Kjaeraas (16/43) Apr 27 2008 Works. See above.
- Bruno Medeiros (7/26) Apr 28 2008 Yes, that's pretty much the bug I mentioned in the original post (the
- Robert Fraser (2/4) Apr 28 2008 Descent's parser isn't D2-ready yet.
- Bruno Medeiros (10/15) Apr 28 2008 I wasn't using Descent, but Mmrnmhrm. :)
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
On 27/04/2008, Bruno Medeiros <brunodomedeiros+spam com.gmail> wrote:and tell which ones you think are valid and which are not. Before runningHere goes:int a = inv_num;OKinvariant(int) b = num;OKconst(int)[] c = inv_intArray;OKint[] d = inv_intArray;ERRORObject e = inv_object;ERRORStruct f = inv_Struct;OK
Apr 27 2008
Janice Caron wrote:On 27/04/2008, Bruno Medeiros <brunodomedeiros+spam com.gmail> wrote: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#Dand tell which ones you think are valid and which are not. Before runningHere goes:int a = inv_num;OKinvariant(int) b = num;OKconst(int)[] c = inv_intArray;OKint[] d = inv_intArray;ERRORObject e = inv_object;ERRORStruct f = inv_Struct;OK
Apr 28 2008
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
Janice Caron wrote:2008/4/29 Bruno Medeiros <brunodomedeiros+spam com.gmail>: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#DHum, 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.
Apr 29 2008
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
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. -- SimenYes, 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
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
Robert Fraser wrote:Bruno Medeiros wrote: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#DSomewhere during the const discussions, I fired up Eclipse (shameless publicity)Descent's parser isn't D2-ready yet.
Apr 28 2008