mutable, const, immutable guidelines

[Daniel Davidson]

On Wednesday, 9 October 2013 at 23:05:27 UTC, qznc wrote:
> 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.

I don't think that is how people interpret and use const. The 
general guideline is, for function parameters use const because 
it is most accepting - it takes mutable, immutable and const. If 
there are multiple threads developer beware.

Threading is or can be somewhat orthogonal to function signatures 
simply because you can write a whole lot of code with the const 
guideline above. Then with proper serialized access use that 
thread unaware code in multi-threaded context.