On Wednesday, 17 October 2018 at 14:14:56 UTC, Nicholas Wilson
wrote:
On Wednesday, 17 October 2018 at 07:24:13 UTC, Stanislav Blinov
wrote:
On Wednesday, 17 October 2018 at 05:40:41 UTC, Walter Bright
wrote:
When Andrei and I came up with the rules for:
mutable
const
shared
const shared
immutable
and which can be implicitly converted to what, so far nobody
has found a fault in those rules...
Here's one: shared -> const shared shouldn't be allowed.
Mutable aliasing in single-threaded code is bad enough as it
is.
Could you explain that a bit more? I don't understand it,
mutable -> const is half the reason const exists.
Yes, but `shared` is not `const`. This 'might change' rule is
poisonous for shared data: you essentially create extra work for
the CPU for very little gain. There's absolutely no reason to
share a read-only half-constant anyway. Either give immutable, or
just flat out copy.
I was thinking that mutable -> shared const as apposed to
mutable -> shared would get around the issues that Timon posted.
It wouldn't, as Timon already explained. Writes to not-`shared`
mutables might just not be propagated beyond the core. Wouldn't
happen on amd64, of course, but still. It's not about atomicity
of reads, it just depends on architecture. On some systems you
have to explicitly synchronize memory.
