Vision for the D language - stabilizing complexity?

[Shachar Shemesh via Digitalmars-d]

On 12/07/16 08:33, Andrei Alexandrescu wrote:
> On 07/12/2016 01:15 AM, Shachar Shemesh wrote:
>> 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?


UFCS: Anywhere you can do "func(a)" you can also do "a.func()" and vice 
versa.

Operator ->: Not needed, as we know this is a pointer to a struct. We 
automatically dereference with the dot operator.

struct A {
     void method() {}
}

void main() {
     A* a;

     a.method(); // Okay
     method(a);  // Not okay
}



>
>> 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).

Nah, this is cut and dried. You should just continue being nicely 
turbed. "Casting away immutability has undefined behavior" is what it 
is. [1]

It is quite okay, and even unavoidable, to go outside the type system 
inside an allocator. It something else entirely to invoke UB.

The C++ definition is quite solid. Casting away constness is UB IFF the 
buffer was originally const.

In this case, your allocator does two UBs. One when allocating (casting 
a mutable byte range to immutable reference), and another when 
deallocating. Both are defined as undefined by D, which means the 
compiler is free to wreak havoc in both without you having the right to 
complain.

Which leads me to the conclusion that you cannot write an allocator in 
D. I doubt that's a conclusion you'd stand behind.

Shachar

1 - https://forum.dlang.org/post/nlsbtr$2vaq$1@digitalmars.com