On Sunday, 15 December 2013 at 22:53:19 UTC, Uplink_Coder wrote:
On Sunday, 15 December 2013 at 11:52:17 UTC, Timon Gehr wrote:
On 12/15/2013 02:20 AM, Walter Bright wrote:
On 12/14/2013 4:36 PM, Timon Gehr wrote:
I cannot cast data from my own storage allocator to
immutable because the
behaviour will be undefined.
http://dlang.org/const3.html
Is this a documentation bug? What should be the actual rules?
It means it's up to you to ensure it is correct.
Undefined behaviour is a term with a precise meaning. That
site says that casting a reference to immutable while there
are still live mutable references to memory reachable by that
reference leads to undefined behaviour. It is not possible to
'ensure it is correct'.
being picky with words is not the right way to argue :D
anyhow.
since we are programmers we can change meaning perfectly well
<code>
alias good bad;
</code> there :D
Undefined behaviour may have a precise meaning to a academic,
but for me as a programmer it means. AVOID THIS SITUATION !!!
unless you know what you do!
Undefined behaviour for a compiler is a point where certin
garuntees MAY be broken. casting something says : "Compiler my
friend: Trust Me, I know what I do" and since neither the
compiler nor the compiler-writer can know wether you are REALLY
trustworthy it can't and doesn't define behaviour for that case.
In this case you have to picture langauge as obeying the
open-closed principle.
The advice Walter gave was adding to the avilable Information
not subsituting it.
Strict, well-defined definitions are important for communication
on technical subjects.
Undefined behaviour means "goodbye logic". Excepting the extreme
case of hacking something for a specific compiler version, you
should never use it. By definition, you cannot know what you're
doing.
Having mutable references to immutable data is not undefined
behaviour. The normal logic of the program is guaranteed to not
be broken by them.
The line lies at modifying the data, not at the existence of the
reference.
