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 = ???
