On Friday, 19 October 2018 at 15:46:20 UTC, Stanislav Blinov
wrote:
On Friday, 19 October 2018 at 13:40:54 UTC, Dominikus Dittes
Scherkl wrote:
Conflating "shared" and "threadsave" in that manner was, I
think, the biggest mistake of your proposal.
He talked about it in a previous thread, and generally I would
agree with him that such conflation is indeed beneficial
provided that some concessions are made for `shared`. Moreover,
yet another attribute? Please no...
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.
