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.
