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