Shared - Another Thread

[Dominikus Dittes Scherkl]

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.