shared - i need it to be useful

[Steven Schveighoffer]

On 10/17/18 12:27 PM, Nicholas Wilson wrote:
> On Wednesday, 17 October 2018 at 15:51:04 UTC, Steven Schveighoffer wrote:
>> On 10/17/18 9:58 AM, Nicholas Wilson wrote:
>>> On Wednesday, 17 October 2018 at 13:25:28 UTC, Steven Schveighoffer 
>>> wrote:
>>>> It's identical to the top one. You now have a new unshared reference 
>>>> to shared data. This is done WITHOUT any agreed-upon synchronization.
>>>
>>> It isn't, you typo'd it (I originally missed it too).
>>>> int *p3 = cast(int*)p2;
>>>
>>> vs
>>>
>>>> int *p3 = p;
>>
>> It wasn't a typo.
> 
> The first example assigns p2, the second assigns p (which is thread 
> local) _not_ p2 (which is shared), I'm confused.
> 

Here they are again:

int *p;
shared int *p2 = p;
int *p3 = cast(int*)p2;

int *p;
shared int *p2 = p;
int *p3 = p;


I'll put some asserts in that show they accomplish the same thing:

assert(p3 is p2);
assert(p3 is p);
assert(p2 is p);

What the example demonstrates is that while you are trying to disallow 
implicit casting of a shared pointer to an unshared pointer, you have 
inadvertently allowed it by leaving behind an unshared pointer that is 
the same thing.

While we do implicitly allow mutable to cast to const, it's because 
const is a weak guarantee. It's a guarantee that the data may not change 
via *this* reference, but could change via other references.

Shared doesn't have the same characteristics. In order for a datum to be 
safely shared, it must be accessed with synchronization or atomics by 
ALL parties. If you have one party that can simply change it without 
those, you will get races.

That's why shared/unshared is more akin to mutable/immutable than 
mutable/const.

It's true that only one thread will have thread-local access. It's not 
valid any more than having one mutable alias to immutable data.

-Steve