Logical const

Bruno Medeiros brunodomedeiros+spam at com.gmail
Fri Dec 3 08:23:48 PST 2010


On 03/12/2010 13:22, Steven Schveighoffer wrote:
> On Fri, 03 Dec 2010 08:00:43 -0500, Bruno Medeiros
> <brunodomedeiros+spam at com.gmail> wrote:
>
>> The above are not trivial differences, so I do not agree that it
>> constitutes full logical const, only a limited form of it. More
>> concretely, it doesn't constitute logical const in in the sense where
>> you can use that as argument to say "logical const already exists,
>> it's just clunky to use", so let's add it to the language formally.
>> Like if mutable members where just syntax sugar, or a betterment of
>> safety rules.
>
> I disagree, I think it does prove logical const already exists. How do
> you define logical const?
>

I define logical const as the ability to specify that operations on a 
given object reference will not modify the logical state of that object 
(through that reference), and the ability for the compiler to verify 
that statically. Logical state is defined (_not very precisely though_) 
as the data subset of an object which is relevant for opEquals 
calculations. So in that Matrix example the elements of the Matrix 
arrays are part of the logical state, the cached determinant is not.

Mutable members is one way to implement support for logical const in a 
language. (There could be other ways.)


 >> Second, there's the TLS thing. I don't think you can just "update it a
 >> bit", there would be significant changes, maybe not in code size, but
 >> in runtime effect: You would need to make it global shared, and thus
 >> have to synchronize the access to the _mutable global. This is quite
 >> significant.
 >
 > I actually re-read the code and realized that it should work without any
 > changes (sans the issue you bring up below with implicit sharing of
 > immutable).
 >

You mean if you wanted to pass a mutable object back and forth?
No it wouldn't, if I understood you correctly. It would merely compile, 
but not work (in the general case). So you would create an object, cast 
it to shared (which means access would now need to be synchronized), and 
pass it to another thread, right? However when you pass to another 
thread the TLS part of the object state is lost (aka the _mutable part). 
That might be valid for cached data that can be recalculated (like the 
determinant), but it would not be valid for other kinds of mutable data 
that the object would require and should not be cleared (like the parent 
Widget in the other example you gave).


-- 
Bruno Medeiros - Software Engineer


More information about the Digitalmars-d mailing list