On Wednesday, 13 July 2016 at 00:03:04 UTC, Walter Bright wrote:
On 7/12/2016 6:13 AM, John Colvin wrote:
On Tuesday, 12 July 2016 at 10:19:04 UTC, Walter Bright wrote:
On 7/12/2016 2:40 AM, John Colvin wrote:
For the previous statement to be false, you must define
cases where
casting away immutability *is* defined.
@system programming is, by definition, operating outside of
the
language guarantees of what happens. It's up to you, the
systems
programmer, to know what you're doing there.
This is so, so wrong. There's a world of difference between
"you have to
get this right or you're in trouble" and "the compiler (and
especially
the optimiser) is free to assume that what you're doing never
happens".
Undefined behaviour, as used in practice by modern optimising
compilers,
is in the second camp. You might have a different definition,
but it's
not the one everyone else is using and not the one that our
two fastest
backends understand.
Given the definition of undefined behaviour that everyone else
understands, do you actually mean "modifying immutable data by
any means
is undefined behaviour" instead of "casting away immutable is
undefined
behaviour"?
What's the difference?
"Casting away immutable is undefined behaviour": the following
code has undefined results (note, not implementation defined, not
if-you-know-what-you're-doing defined, undefined), despite not
doing anything much:
void foo()
{
immutable a = new int;
auto b = cast(int*)a;
}
"modifying immutable data is undefined": The above code is fine,
but the following is still undefined:
void foo()
{
immutable a = new int;
auto b = cast(int*)a;
b = 3;
}
Anyhow, if you cast away immutability, and the data exists in
rom, you still can't write to it (you'll get a seg fault). If
it is in mutable memory, you can change it, but other threads
may be caching or reading the value while you do that, i.e.
synchronization issues. The optimizer may be taking advantage
of immutability in its semantic transformations.
As a systems programmer, you'd have to account for that.
Something like "it might be in ROM" is an implementation detail.
It's the optimiser part that forces a formal decision about what
is undefined behaviour or not.
Implementation defined behaviour is in the realm of the "systems
programming, be careful you know what you're doing". Undefined
behaviour is a different beast.
