Logical const

Bruno Medeiros brunodomedeiros+spam at com.gmail
Thu Dec 2 10:38:55 PST 2010


On 29/11/2010 23:04, Walter Bright wrote:
> Steven Schveighoffer wrote:
>> On Mon, 29 Nov 2010 15:58:10 -0500, Walter Bright
>> <newshound2 at digitalmars.com> wrote:
>>
>>> Steven Schveighoffer wrote:
>>>> Having a logical const feature in D would not be a convention, it
>>>> would be enforced, as much as const is enforced. I don't understand
>>>> why issues with C++ const or C++'s mutable feature makes any
>>>> correlations on how a D logical const system would fare. C++ const
>>>> is not D const, not even close.
>>>
>>>
>>> Because people coming from C++ ask "why not do it like C++'s?"
>>
>> I don't get it. A way to make a field mutable in a transitively-const
>> system is syntactically similar to C++, but it's not the same. Having
>> a logical-const feature in D does not devolve D's const into C++'s
>> const. If anything it's just a political problem.
>
> Having mutable members destroys any guarantees that const provides.
> That's not political.
>

That is not true, trivially. (assuming we are talking about D)

Having mutable members only (slightly) modifies the guarantees of const. 
For example:

class Foo {
   int x, y, z;
   mutable int blah;
}

void someFunc(const Foo foo) { ... }


here someFunc is still guaranteed to not modify any data transitively 
reachable through the foo reference, _with the exception of mutable 
members_. Is this still a useful guarantee? Well yes, for example in 
Peter's Matrix example, I could pass a const(Matrix) as an argument and 
still be confident that at most, only the mutable members would be 
change (the cached determinant), but not the logical state. The compiler 
would be able to check this, just as much as with D's current const.

Also, it would still guarantee that immutable data passed to that 
function is not transitively modified (with the exception of mutable 
members). And that is the main point of const.


A more interesting question is whether mutable members would 
significantly alter the guarantees of *immutable*. They would not 
changue the guarantee of immutable with regards to single-threaded 
optimization. So if a function has an immutable object, it can still 
assume the non-mutable members don't change, and optimize accordingly.

However, a big thing that could no longer be guaranteed, is that you 
would be able to safely pass an immutable object to a function running 
in another thread, without synchronization. This is because said 
function would be allowed to mutate the mutable members, but these could 
be being accessed concurrently, so...


-- 
Bruno Medeiros - Software Engineer


More information about the Digitalmars-d mailing list