Logical const

[Steven Schveighoffer]

On Wed, 01 Dec 2010 18:34:34 -0500, Walter Bright  
<newshound2 at digitalmars.com> wrote:

> Steven Schveighoffer wrote:
>> 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).
>
> foo() could only modify c if it has, via some other means, acquired a  
> mutable reference to c. If the user does not provide this other mutable  
> reference, then foo() cannot modify c. foo() cannot go out and grab or  
> create such a reference.

You're assuming the domain of c's state stops at its scope.  In fact,  
except for in pure functions, c's 'state' includes all global variables as  
well.  There is nothing stopping a programmer from using something outside  
the object/struct itself to store some state of c.  Those external data  
members would essentially be mutable (as I have shown in the past).  This  
takes most of the teeth out of const's guarantees.

> This is quite the opposite from what you're proposing. Currently, the  
> user has to make it possible for foo() to modify c, whereas your  
> proposal is that foo() can modify c despite all attempts by the user to  
> stop it.

Not exactly.  My proposal recognizes that we have to trust the programmer  
to only use mutable state (or external state in the current const  
implementation) to represent 'non-state' variables, that is, variables  
that are not considered part of the object itself.  This includes  
references to unowned data (like an output stream) or cached computations  
(which are not part of the state, they are an optimization).  My proposal  
allows the programmer to store that state inside the object.  All const  
guarantees on the actual state variables is fully enforced.

The question is, is the user of c concerned about const-ifying data  
members that are non-state members?  Usually no.  They only care about  
variables that are part of the state of the object.

> Furthermore, if you mark foo() as pure, the compiler can guarantee there  
> is no such hidden mutable reference.

Pure is an area where logical const would have to follow special rules.   
My inclination is that pure functions would have no access to members  
marked as 'no-state'.  That would at least be consistent with the current  
implementation of logical const.

This can have implications as far as copying value-types (what do you do  
with the mutable members?), but I think we could work out those rules.

-Steve