mutable, const, immutable guidelines

[qznc]

On Wednesday, 9 October 2013 at 15:50:55 UTC, Daniel Davidson 
wrote:
> void foo(const(MutableType) mt);
> void foo(immutable(MutableType) mt);
>
> Naturally the inclination is to choose the second as it is a 
> stronger guarantee that no threads are changing the data. Cool. 
> But wait, the first one still probably requires the same 
> guarantee, even if it does not state it. If in the const case 
> another thread changes the state of mt during the function foo 
> then it will fail. foo actually requires that mt not be change 
> by other threads during its operation - that is the only sane 
> way of using the data in the function.

Why "the first one still probably requires the same guarantee"?
Why would foo fail if "in the const case  another thread changes 
the state of mt"?
If foo is not thread-safe, then it should require immutable.

> Take, for example, LinearCongruentialEngine from random.d. It 
> has a function:
>
>     bool opEquals(ref const LinearCongruentialEngine rhs) const
>
> Why is it using const here instead of immutable? Does it not 
> care about other threads? No - it just is not smart enough to 
> deal with it. It assumes other threads won't be changing it or 
> if they are caveat developer. So when do you use immutable as a 
> signal that not only will this function not change it, no 
> thread will change it either? Probably when you know you have 
> to deal with threading. But that then would be coupling two 
> maybe orthogonal decisions - the threading of a program and the 
> signature of functions.

Hm, that actually looks like a bug. If LinearCongruentialEngine 
is instantiated with a UIntType larger than size_t, it is not 
thread-safe, but this seems to be claimed in the section header.

Why are those two decisions orthogonal? The signature of a 
function is a contract between caller and callee. If an argument 
is const, it means the callee says he can handle others changing 
the state concurrently.