Vision for the D language - stabilizing complexity?

[H. S. Teoh via Digitalmars-d]

On Tue, Jul 12, 2016 at 01:33:00AM -0400, Andrei Alexandrescu via Digitalmars-d wrote:
> On 07/12/2016 01:15 AM, Shachar Shemesh wrote:
[...]
> > Casting away immutability is UB in D.
> 
> I understand. There is an essential detail that sadly puts an
> anticlimactic end to the telenovela. The unsafe cast happens at
> allocator level.
[...]

What's an "unsafe cast"?  I think we're mixing up terminology here,
which is not helping this discussion.

Is casting away immutable merely *unsafe*, or is it UB?

Because if it's UB (as understood by the rest of the world), then your
statement essentially amounts to saying that allocators are UB. Which in
turn means that optimizing compilers are free to assume that allocaters
are impossible (since they are UB and the compiler is therefore free to
do whatever it wants there, such as assume that it cannot ever happen),
and, in all likelihood, output garbage in the executable as a result.

If you don't mean UB in this sense of the term, then you (well, the D
language spec) need to define what exactly is supposed to happen when
immutable is cast away. Exactly when is such a cast UB, and when is it
*not* UB?  (I'm assuming that casting away immutable in the general case
is UB, e.g., if the compiler puts such memory in ROM. But since this
isn't always the case, e.g., you're allocating a block of mutable memory
from RAM but designating it as immutable for the purposes of the type
system, then the spec needs to specify exactly when such casts will not
result in UB, to allow room for allocators to be implementable. If all
the spec says is a blanket statement that such casts are UB, then by
definition of UB all such allocator code is invalid, and an optimizing
compiler is free to "optimize" it away (with disastrous results).)

Or perhaps what you *really* mean is that casting away immutable is
*implementation-defined*, not UB. The two are not the same thing. (But
even then, you may still run into trouble with implementations that
define a behaviour that doesn't match what, e.g., the allocator code
assumes. These things need to be explicitly stated in the spec so that
implementors won't do something outside of what you intended -- whether
deliberate or as a misunderstanding of what the intent of the spec was.)


T

-- 
There is no gravity. The earth sucks.