On 12/15/2013 11:53 PM, 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
Of course it is. http://en.wikipedia.org/wiki/Mathematical_logic
Logic is the right way to reason whenever it is applicable. An example
of when it is not applicable is during a debate on whether the last
statement was valid. However, reasonable people will agree.
Here the goal is to describe programming language semantics in a precise
way, so logic is clearly applicable. Knowing what one is actually saying
(relative to some logic) is necessary in order to do this in any
meaningful fashion.
anyhow.
since we are programmers we can change meaning perfectly well
<code>
alias good bad;
</code> there :D
I see neither your point nor how your example illustrates it.
Undefined behaviour may have a precise meaning to a academic, but for me
as a programmer it means. AVOID THIS SITUATION !!!
This is close enough to the "precise academic meaning" to leave
everything I have stated meaningful.
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.
This part is nonsense. (Also, we are not arguing about what some
specific compiler is doing. A specific compiler version will usually
define the semantics of a portion of code for each back-end architecture
in a more fine-grained way than mandated by the language standard,
specified in its documentation and/or unspecified.)
The language defines behaviour conditional on "trustworthiness of the
programmer". E.g. dereferencing a pointer in C has defined behaviour as
long as the pointer is valid, according to a precise definition of
valid. It is not the case that dereferencing a pointer in C never has
defined behaviour just because one cannot verify validity automatically
in general. This does not have to be possible in order to have a
meaningful language specification.
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.
Hence I was asking whether the spec is in need of an update.
