Vision for the D language - stabilizing complexity?

Andrei Alexandrescu via Digitalmars-d digitalmars-d at puremagic.com
Tue Jul 12 07:26:04 PDT 2016


On 07/12/2016 03:35 AM, Shachar Shemesh wrote:
> 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
> }

Thanks. I must have misunderstood - I was looking for something that's 
not @safe.

>>> 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]

AffixAllocator is not casting away immutability - that's the beauty of 
it. But I'm all for making the language more precise to allow the kind 
of work AffixAllocator does portably. Would love some help from you there!

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

Yeah, we might relax that in D as well, albeit for different reasons.

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

Again, your help with improving the language definition would be very 
welcome. Obviously we do want to have AffixAllocator and other 
allocators work properly.


Andrei




More information about the Digitalmars-d mailing list