Vision for the D language - stabilizing complexity?

Shachar Shemesh via Digitalmars-d digitalmars-d at puremagic.com
Tue Jul 12 07:53:05 PDT 2016


On 12/07/16 17:26, Andrei Alexandrescu wrote:

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

No, I was referring to his statement that features in D tend to create 
complexity and unexpected/non-intuitive behavior when combined. Sorry if 
I was not clear.

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

This is a bit academic, but I don't understand how you can get an 
immutable/const pointer to memory, and then get a pointer to a mutable 
uint out of it without casting away the constness. Yes, you are 
subtracting the pointer so it points to outside the original memory, but 
technically speaking (which is all the compiler really sees, at this 
point), you are casting "immutable MyClass*" to "uint*". It is only 
semantically that you know this is fine.

Saw your reference to the code in a different comment. I believe (and I 
might be wrong) the cast in question to be here:
https://github.com/dlang/phobos/blob/master/std/experimental/allocator/building_blocks/affix_allocator.d#L213

The input might be CI. The output is mutable.

If such cast is UB, then the compiler is free to say "this is nonsense, 
I'm not going to do it". If we use the C++'s UB definition, the compiler 
can say "I hereby assume that the buffer is actually mutable". This is, 
potentially, completely different code generation.

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

I would love to hear about what are D's reasons, and in what way they 
are different than C++'s. To clarify, the previous sentence was meant to 
be read with no cynicism intended.

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

I was thinking about intrusive reference counting, which is the classic 
case I'd use "mutable" in C++. In that case, the value we're mutating 
actually is a member of the struct that was passed as const (I think 
immutable isn't an issue in that use case).

I think a great first step is to relax the UB around casting away CI 
modifiers where we know, semantically, that the underlying memory is 
actually mutable.

Shachar


More information about the Digitalmars-d mailing list