shared - i need it to be useful

[Stanislav Blinov]

On Saturday, 20 October 2018 at 16:48:05 UTC, Nicholas Wilson 
wrote:
> On Saturday, 20 October 2018 at 09:04:17 UTC, Walter Bright 
> wrote:
>> On 10/19/2018 11:18 PM, Manu wrote:
>>> The reason I ask is because, by my definition, if you have:
>>> int* a;
>>> shared(int)* b = a;
>>> 
>>> While you have 2 numbers that address the same data, it is 
>>> not actually aliased because only `a` can access it.
>>
>> They are aliased,
>
> Quoting Wikipedia:
>
>>two pointers A and B which have the same value, then the name 
>>A[0] aliases the name B[0]. In this case we say the pointers A 
>>and B alias each other. Note that the concept of pointer 
>>aliasing is not very well-defined – two pointers A and B may or 
>>may not alias each other, depending on what operations are 
>>performed in the function using A and B.
>
> In this case given the above: `a[0]` does not alias `b[0]` 
> because `b[0]` is ill defined under Manu's proposal, because 
> the memory referenced by `a` is not reachable through `b` 
> because you can't read or write through `b`.
>
>> by code that believes it is unshared
>
> you cannot `@safe`ly modify the memory  through `b`, `a`'s view 
> of the memory is unchanged in @safe code.

And that's already a bug, because the language can't enforce 
threadsafe access through `a`, regardless of presence of `b`. 
Only the programmer can.

>> and, code that believes it is shared.
>
> you cannot have non-atomic access though `b`, `b` has no @safe 
> view of the memory, unless it is atomic (which by definition is 
> synchronised).

Synchronized with what? You still have `a`, which isn't `shared` 
and doesn't require any atomic access or synchronization. At this 
point it doesn't matter if it's an int or a struct. As soon as 
you share `a`, you can't just pretend that reading or writing `a` 
is safe. Encapsulate it all you want, safety only remains a 
contract of convention, the language can't enforce it.