Vision for the D language - stabilizing complexity?

[Andrei Alexandrescu via Digitalmars-d]

On 07/12/2016 01:15 AM, Shachar Shemesh wrote:
> On 08/07/16 22:26, Andrei Alexandrescu wrote:
>
>> I agree with that. What would be a good example? Where is the reference
>> to Walter's promotion of UB in @safe code?
>>
>>
>> Andrei
>
> I don't have an example by Walter, but I can give you an example by Andrei.
>
> In D-Conf.
>
> On Stage.
>
> During the keynotes.
>
> Immediately after knocking down C++ for doing the precise same thing,
> but in a that is both defined and less likely to produce errors.

Love the drama. I was quite excited to see what follows :o).

> The topic was reference counting's interaction with immutable (see
> deadalnix's comment, to which I completely agree, about inter-features
> interactions).

Amaury failed to produce an example to support his point, aside from a 
rehash of a bug report from 2013 that is virtually fixed. Do you have any?

> When asked (by me) how you intend to actually solve this,
> you said that since you know where the memory comes from, you will cast
> away the immutability.
>
> 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. Inside any memory allocator, there is a point at which 
behavior outside the type system happens: memory that is untyped becomes 
typed, and vice versa (during deallocation). As long as you ultimately 
use system primitives from getting untyped bytes, at some point you'll 
operate outside the type system. It stands to reason, then, that at 
allocator level information and manipulations outside the type system's 
capabilities are possible and level so long as such manipulations are 
part of the standard library and offer defined behavior. This is par for 
the course in C++ and any systems language.

The solution (very ingenious, due to dicebot) in fact does not quite 
cast immutability away. Starting from a possibly immutable pointer, it 
subtracts an offset from it. At that point the memory is not tracked by 
the type system, but known to the allocator to contain metadata 
associated with the pointer that had been allocated with it. After the 
subtraction, the cast exposes the data which is mutable without 
violating the immutability of the object proper. As I said, it's quite 
an ingenious solution.

> Not long before that, you laughed at C++ for it's "mutable" keyword,
> which allows doing this very thing in a way that is:
> A. Fully defined (if you know what you're doing)
> and
> B. Not requiring a cast

I think we're in good shape with what we have; mutable has too much 
freedom and it's good to get away without it.



Andrei