Shared - Another Thread

[Nicholas Wilson]

On Saturday, 20 October 2018 at 00:00:49 UTC, Dominikus Dittes 
Scherkl wrote:
> Hmm.
> mutable, immutable and const form a triple, the second is a 
> declaration attribute, the last an parameter attribute, 
> indicating that you don't want to modify the parameter, may it 
> be because you can't (as it is immutable) or you only don't 
> need to despite it would be possible (if it was mutable). The 
> later is your responsibility to guarantee (with the help from 
> the compiler).
> Therefore it is possible to implicitly cast from mutable or 
> immutable to const but not in any other direction.
>
> I think for unshared, shared and threadsave it should be the 
> same:
> The second is a declaration attribute, the third a parameter 
> attribute. The first two can implicitly be cast to threadsave, 
> may be because it is thread-local and therefore no race 
> condition is possible, or may be because you take special care 
> in your type to guarantee the thread safety by using atomic 
> operations or locking or whatever.
> That make it possible, that the implicit cast from shared to 
> unshared can be avoided while still providing functions that 
> can take both kinds of arguments.
>
> Yes, that would add a little to the attribute bloat (new 
> keyword) but not to the number of attributes per type or 
> parameter.

Mutable = value may change
const = I will not change the value
immutable = the value will not change

unshared = I (well the current thread) owns the reference
shared = reference not owned, no unordered access, no (unordered) 
writes
threadsafe = ???