www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - What am I missin with const?

reply "estew" <estewh gmail.com> writes:
Hi,

Just started in D a week back after years of C/C++ head bashing 
and have to say language is fantastic.

I have a small misunderstanding regarding const...well ok, a 
fundamental misunderstanding by the looks of it:)

class A
{

ulong[] values;
...
const ulong[] getValue() const {
     return this.values;
}

}

But this fails to compile with the following message:
Error: cannot implicitly convert expression (this.values) of type 
const(ulong[]) to ulong[]

I just do not see it in the code. The function is const, so 
this.values is const, and I am just returning that as a const 
ulong[]. Am I not???


I don't get it? Any help explaining why this does not compile 
would be appreciated!

Thanks,
Stewart
Jan 28 2013
next sibling parent "estew" <estewh gmail.com> writes:
Sorry all, I just need to read the docs more carefully and do 
more homework! Especially the section "Immutable Member 
Functions" under Const and Immutable.


...couldn't be more obvious :-)

Cheers,
Stewart
Jan 28 2013
prev sibling next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 29 January 2013 at 05:36:31 UTC, estew wrote:
 Hi,

 Just started in D a week back after years of C/C++ head bashing 
 and have to say language is fantastic.

 I have a small misunderstanding regarding const...well ok, a 
 fundamental misunderstanding by the looks of it:)

 class A
 {

 ulong[] values;
 ...
 const ulong[] getValue() const {
     return this.values;
 }

 }

 But this fails to compile with the following message:
 Error: cannot implicitly convert expression (this.values) of 
 type const(ulong[]) to ulong[]

 I just do not see it in the code. The function is const, so 
 this.values is const, and I am just returning that as a const 
 ulong[]. Am I not???


 I don't get it? Any help explaining why this does not compile 
 would be appreciated!

Hi, This is a very common syntax trap where too many people fall. When you do const ulong[] getValue() const both const are qualifying this, and none the return value. So the error. The correct declaration is : const(ulong)[] getValue() const or const(ulong[]) getValue() const I wish this syntax will be fixed, but I have no hope. We just will see the problem popping again and again I guess.
Jan 28 2013
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 01/29/2013 10:38 AM, deadalnix wrote:
 On Tuesday, 29 January 2013 at 09:10:28 UTC, bearophile wrote:
 deadalnix:

 I wish this syntax will be fixed, but I have no hope. We just will
 see the problem popping again and again I guess.

I asked for that fix, but Walter closed down that request in Bugzilla. I still think he was wrong. I now open a smaller request that can't fix the problem fully: http://d.puremagic.com/issues/show_bug.cgi?id=9422

Well I think the error message you propose isn't possible as it would cause many problems in generic code.

How?
 const applied to the rturn type should be the way to go. It is basically
 what everybody except at first when looking at the code. But it is
 probably too late to change that.

The current behaviour emerges because the parser treats const void foo(){} exactly like const{ void foo(){} }
Jan 29 2013
parent Nick Treleaven <ntrel-public yahoo.co.uk> writes:
On 29/01/2013 10:21, Era Scarecrow wrote:
 On Tuesday, 29 January 2013 at 09:45:17 UTC, Timon Gehr wrote:
 On 01/29/2013 10:38 AM, deadalnix wrote:
 Well I think the error message you propose isn't possible as it would
 cause many problems in generic code.

How?
 const applied to the return type should be the way to go. It is
 basically what everybody except at first when looking at the code.
 But it is probably too late to change that.

The current behavior emerges because the parser treats const void foo(){} exactly like const{ void foo(){} }

Somehow that's what I'd prefer, Consistency. If it's an int, then these two could be very confusing based on location of const. So if const is unattached it is for the whole function const int foo() //misleading vs int foo() const However specifying an item that's const will always result in the correct const of that type. There's never ambiguity following those rules; Although those coming from C++ will need to put the extra effort to specify which is const. const(int) foo() vs int foo() const

There is unnecessary syntactic ambiguity for users unaware of the problem (or aware users that are tired so not able to recognize the problem immediately). This is exactly the same reason dmd warns about a dangling else: if (x) if (y){} else {} // warning: dangling else The above is consistent and correct code from the compiler's point of view, but is bug-prone for humans, so the compiler complains. The fact it comes up in the newsgroups periodically is proof the current syntax is confusing.
Jan 30 2013
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
deadalnix:

 I wish this syntax will be fixed, but I have no hope. We just 
 will see the problem popping again and again I guess.

I asked for that fix, but Walter closed down that request in Bugzilla. I still think he was wrong. I now open a smaller request that can't fix the problem fully: http://d.puremagic.com/issues/show_bug.cgi?id=9422 Bye, bearophile
Jan 29 2013
prev sibling next sibling parent kenji hara <k.hara.pg gmail.com> writes:
--f46d043893bdd13dd804d469ec85
Content-Type: text/plain; charset=UTF-8

Could you link to the issue Walter closed down from issue 9422?

Kenji Hara


2013/1/29 bearophile <bearophileHUGS lycos.com>

 deadalnix:


  I wish this syntax will be fixed, but I have no hope. We just will see
 the problem popping again and again I guess.

I asked for that fix, but Walter closed down that request in Bugzilla. I still think he was wrong. I now open a smaller request that can't fix the problem fully: http://d.puremagic.com/issues/**show_bug.cgi?id=9422<http://d.puremagic.com/issues/show_bug.cgi?id=9422> Bye, bearophile

--f46d043893bdd13dd804d469ec85 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Could you link to the issue Walter closed down from issue = 9422?<br><div><br></div><div>Kenji Hara</div><div class=3D"gmail_extra"><br=
<br><div class=3D"gmail_quote">2013/1/29 bearophile <span dir=3D"ltr">&lt;=

S lycos.com</a>&gt;</span><br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex">deadalnix:<div class=3D"im"><br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> I wish this syntax will be fixed, but I have no hope. We just will see the = problem popping again and again I guess.<br> </blockquote> <br></div> I asked for that fix, but Walter closed down that request in Bugzilla. I st= ill think he was wrong.<br> <br> I now open a smaller request that can&#39;t fix the problem fully:<br> <a href=3D"http://d.puremagic.com/issues/show_bug.cgi?id=3D9422" target=3D"= _blank">http://d.puremagic.com/issues/<u></u>show_bug.cgi?id=3D9422</a><br> <br> Bye,<br> bearophile<br> </blockquote></div><br></div></div> --f46d043893bdd13dd804d469ec85--
Jan 29 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 29 January 2013 at 09:10:28 UTC, bearophile wrote:
 deadalnix:

 I wish this syntax will be fixed, but I have no hope. We just 
 will see the problem popping again and again I guess.

I asked for that fix, but Walter closed down that request in Bugzilla. I still think he was wrong. I now open a smaller request that can't fix the problem fully: http://d.puremagic.com/issues/show_bug.cgi?id=9422

Well I think the error message you propose isn't possible as it would cause many problems in generic code. const applied to the rturn type should be the way to go. It is basically what everybody except at first when looking at the code. But it is probably too late to change that.
Jan 29 2013
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
kenji hara:

 Could you link to the issue Walter closed down from issue 9422?

I have taken part of that discussion thread, but the bug report was created by Simen Kjaeraas: http://d.puremagic.com/issues/show_bug.cgi?id=4070 (Maybe in Bugzilla there is another similar closed issue, because I vaguely remember Jonathan commenting on it.) Bye, bearophile
Jan 29 2013
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
deadalnix:

 Well I think the error message you propose isn't possible as it 
 would cause many problems in generic code.

Please, add one or two of such troubled cases in the issue thread: http://d.puremagic.com/issues/show_bug.cgi?id=9422 Bye, bearophile
Jan 29 2013
prev sibling next sibling parent "monarch_dodra" <monarchdodra gmail.com> writes:
On Tuesday, 29 January 2013 at 09:50:37 UTC, bearophile wrote:
 deadalnix:

 Well I think the error message you propose isn't possible as 
 it would cause many problems in generic code.

Please, add one or two of such troubled cases in the issue thread: http://d.puremagic.com/issues/show_bug.cgi?id=9422 Bye, bearophile

For what it's worth, I think 9422 is better than 4070. You rarely see const on the return type without also putting it on the function too, so this should catch *most* accidental usage. It also still allows the syntax for those that enjoy qualifying everything on the previous line: //---- pure property safe const int foo() { ...... } //----
Jan 29 2013
prev sibling parent "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Tuesday, 29 January 2013 at 09:45:17 UTC, Timon Gehr wrote:
 On 01/29/2013 10:38 AM, deadalnix wrote:
 Well I think the error message you propose isn't possible as 
 it would cause many problems in generic code.

How?
 const applied to the return type should be the way to go. It 
 is basically what everybody except at first when looking at 
 the code. But it is probably too late to change that.

The current behavior emerges because the parser treats const void foo(){} exactly like const{ void foo(){} }

Somehow that's what I'd prefer, Consistency. If it's an int, then these two could be very confusing based on location of const. So if const is unattached it is for the whole function const int foo() //misleading vs int foo() const However specifying an item that's const will always result in the correct const of that type. There's never ambiguity following those rules; Although those coming from C++ will need to put the extra effort to specify which is const. const(int) foo() vs int foo() const That's something that was confusing in C++; you could have 'const const int foo()' and it would be correct, but it doesn't really look right; To make it a little less confusing they split it up, but the meaning is still easy to confuse.
Jan 29 2013