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 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 "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
next sibling parent reply kenji hara <k.hara.pg gmail.com> writes:
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
Jan 29 2013
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 parent reply "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
next sibling 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 reply "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
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 parent reply "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
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