Shared - Another Thread

[Dominikus Dittes Scherkl]

On Thursday, 18 October 2018 at 16:24:39 UTC, Manu wrote:
> On Wednesday, 17 October 2018 at 22:56:26 UTC, H. S. Teoh wrote:
>> What cracks me up with Manu's proposal is that it is its 
>> simplicity and lack of ambition that is criticized the most. 
>> shared is a clusterfuck, according to what I gathered from the 
>> forum, I never had yet to use it in my code. Manu's idea makes 
>> it a little less of a clusterfuck, and people attack the idea 
>> because it doesn't solve all and everything that's wrong with 
>> shared. Funny.
>>
>
> Elaborate on this... It's clearly over-ambitious if anything.
> What issues am I failing to address?

First of all, you called it "shared", but what your concept 
describes is "theadsave".
If you had called it the later, it would have been clear to 
everybody that thread local data is indeed automatically 
threadsave, because only one thread has access to it (that 
"implicit conversion"). But if something is "shared" (in the 
common-world sense), it is of course no more "threadsave" - you 
have to implement special methods to treat it.

Conflating "shared" and "threadsave" in that manner was, I think, 
the biggest mistake of your proposal.

Another point is the part of "how can the compiler support the 
expert in writing threadsave methods" - which you answered with 
"not a little bit at the moment, but we may improve this in the 
future" - and that is not at all satisfying. Are there really no 
ideas? No check that the proper atomic funtions are used or the 
cast to "unshared" is ok at where it is used? Even the expert 
needs a little help to find the upcomming and well hidden bugs in 
their oh so threadsave API...