Fully transitive const is not necessary

[Steven Schveighoffer]

"Sean Reque" wrote
> Steven Schveighoffer Wrote:
>
>> "Sean Kelly" wrote
>> > == Quote from Janice Caron article
>> >> ...which raises an interesting point. Can "synchronized" be used on a
>> >> const object? What about an invariant object?
>> >
>> > They'll work just fine with const objects in D.  Object monitors in D
>> > currently
>> > live outside the const checking scheme.
>>
>> Oh so you mean Walter couldn't implement mutexes without logical const 
>> huh?
>> I think this part of the system should be ripped out and you should have 
>> to
>> pass mutexes along with objects everywhere you want to ensure thread 
>> safety
>> and const is transitive.  That's easier and less obfuscated, right?
>>
>> -Steve
>>
>>
>
> The whole point of invariant objects and pure functions in terms of thread 
> safety is that you don't need any form of synchronized data access. If, 
> for instance a piece of data is guaranteed not to change, then two cores 
> can hold two separate copies of the same data in each of their local 
> caches instead of having to fetch the same data from an external source. 
> Requiring synchronization on all const objects would entirely defeat 
> optimizations like these.

Correct, for pure functions.  But for non-pure functions, which is 100% of 
D2 code right now, you do need synchronization.  When pure is introduced, 
then I believe at least 75% of D will not use it (just a guess, but I 
believe more D code will be non-pure than will be pure), and you STILL will 
need synchronization for those functions.  In that case, you still need to 
synchronize at least const objects, and where do we store the mutex?  WITH 
THE OBJECT!   Which means, it is not part of the object state, because 
otherwise you couldn't lock it while the object was const!

I'm not arguing about how mutexes are implemented.  I'm pointing out the 
hipocrasy of how logical const is not allowed for developers, yet Walter 
uses it in the standard library to implement mutexes.

>
> The end result is, don't use const, invariant, or pure if you plan on 
> modifying internal data on an object. A caching calculator, for instance, 
> is inherently not thread safe, because one thread might cause the 
> calculator to write to the cache at the same time another thread reads 
> from it, so the calculator should never be allowed to be const or 
> invariant. If I understand correctly, Walter wants the compiler to be able 
> to make assumptions on an invariant object that would not be possible if 
> it had mutable members.

I'd like to do that, but the way D const works, it's very difficult.  For 
example, what if a calculator is expected to be const? (see the other branch 
of this thread with the arguments between myself and Janice)  Now, I cannot 
pass my caching calculator unless I make the cache a global, which is 
totally unnecessary, it should be piggy-backed around with the calculator 
object, but not part of the object state, just like mutexes are...

>
> I think that the ideas of pure and invariant will be very valuable in the 
> end and one of D's strong selling points. It will require more careful 
> library design though, and some designs and features, such as caching 
> calculations or synchronizing memory access, will simply not be usable 
> with it.

I do not have an opinion on whether pure and invariant will be huge for D, 
as I am not experienced enough with FP, but I know for a fact that having 
logical const will not inhibit this, just as logical const mutexes will not.

-Steve