Shared - Another Thread

[Stanislav Blinov]

On Friday, 19 October 2018 at 13:40:54 UTC, Dominikus Dittes 
Scherkl wrote:
> 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.

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...

struct X {
     void foo(threadsafe const shared Bar* bar) @nogc @trusted 
notrhow pure const shared threadsafe;
}

Attribute explosion is bad enough already.