Vision for the D language - stabilizing complexity?

[Andrei Alexandrescu via Digitalmars-d]

On 07/12/2016 10:53 AM, Shachar Shemesh wrote:
> 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.

I agree we have a few of those, though I don't think your example is 
particularly egregious.

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

That's the code.

> The input might be CI. The output is mutable.

No. It's important to understand that the "input" and "output" are 
distinct because of the [-1]. That gets into memory that was never typed 
as unsafe.

This is a layout matter. It says that if you happen to know some 
immutable data sits 8 bytes to the right of some mutable data, doing the 
appropriate pointer arithmetic on the immutable data takes you correctly 
to the mutable data. I'm all for adding language to the spec to clarify 
that.

> If such cast is UB, then the compiler is free to say "this is nonsense,
> I'm not going to do it".

It's not UB.

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

I understand.

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

You'll need to use AffixAllocator to do intrusive RC.

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

That would not be the right thing to do.


Andrei