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/[email protected]
