Vision for the D language - stabilizing complexity?
John Colvin via Digitalmars-d
digitalmars-d at puremagic.com
Tue Jul 12 06:13:42 PDT 2016
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"?
More information about the Digitalmars-d
mailing list