Logical const

Steven Schveighoffer schveiguy at yahoo.com
Wed Dec 1 13:09:22 PST 2010


On Tue, 30 Nov 2010 16:53:14 -0500, Walter Bright  
<newshound2 at digitalmars.com> wrote:

> Steven Schveighoffer wrote:
>> If you find the above unsurprising, you are in the minority.  I find it  
>> surprising, and invalid that anyone would write code this way.  People  
>> simply just don't do that normally.  It's just written to demonstrate a  
>> point that the compiler does not guarantee anything via const, it's  
>> guaranteed by convention.  The compiler simply helps you follow the  
>> convention.
>
> Ok, I see what you mean now. Your code is relying on there being a  
> mutable alias of the same object.
>
> This is not surprising behavior. It is explicit in how const is defined.  
> It makes sense that const does not have immutable behavior, because  
> otherwise there wouldn't be both const and immutable type constructors.
>
> You're wrong in saying the compiler doesn't guarantee anything with  
> const. I listed the things it does guarantee.

The literal guarantee is that things aren't modified through that  
reference.  The semantic result to someone calling the function is that it  
doesn't guarantee that the data referred to won't change, or that part of  
C's state cannot change through that reference.

If I see a function like:

void foo(const(C) c);

it doesn't mean that foo cannot modify the object referred to by c, it  
just means that foo won't modify data referenced through c.  But a C could  
store some data in a global variable, possibly even uniquely associated  
with each instance (I have shown this in a very old post proving logical  
const == const).  Then logically, the author of C could consider that data  
a part of C.  I have no way to stop him from editing that logical part of  
C, I'm relying on the author of C not to count mutable state as part of  
the state of C.

Adding logical const just provides a location in the object itself for  
this data that is not supposed to be part of C's state.  It's not changing  
the guarantees that const already provides (which is very little, but  
helps you follow the correct conventions).

When it comes to immutable and pure, we would need new rules.

-Steve


More information about the Digitalmars-d mailing list