On Saturday, 20 October 2018 at 17:06:22 UTC, Stanislav Blinov
wrote:
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:
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.
access through `a` is through the owned reference threadsafety
through a does't mean anything, all _other_ access must ensure
that the are ordered correctly.
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.
Synchronized w.r.t any writes to that memory, e.g. from `a`.
At this point it doesn't matter if it's an int
or a struct.
Yes.
As soon as you share `a`, you can't just pretend that reading
or writing `a` is safe.
You can if no-one else writes to it, which is the whole point of
Manu's proposal. Perhaps it should be const shared instead of
shared but still.
