Vision for the D language - stabilizing complexity?

Andrei Alexandrescu via Digitalmars-d digitalmars-d at puremagic.com
Tue Jul 12 11:54:29 PDT 2016


On 07/12/2016 02:53 PM, Lodovico Giaretta wrote:
> On Tuesday, 12 July 2016 at 18:45:00 UTC, Jacob Carlborg wrote:
>> On 2016-07-12 07:33, Andrei Alexandrescu wrote:
>>
>>> The solution (very ingenious, due to dicebot) in fact does not quite
>>> cast immutability away. Starting from a possibly immutable pointer, it
>>> subtracts an offset from it. At that point the memory is not tracked by
>>> the type system, but known to the allocator to contain metadata
>>> associated with the pointer that had been allocated with it. After the
>>> subtraction, the cast exposes the data which is mutable without
>>> violating the immutability of the object proper. As I said, it's quite
>>> an ingenious solution.
>>
>> What if the immutable data is stored in ROM [1]? I assume it's not
>> possible to have an offset to a completely different memory storage.
>>
>> Not sure if this is important enough to care about.
>>
>> [1] http://dlang.org/const-faq.html#invariant
>
> The idea is that in general, you cannot cast away immutability because
> of this. But the allocator knows that the data at (ptr-offset) is not in
> ROM (because it didn't allocate it from ROM), and thus can cast away
> immutability without any issue.
> And the allocator is not violating any type system invariant, because
> there cannot exist any immutable reference to (ptr-offset), given that
> this area was not given away by the allocator.

Thanks for the crisp summary. -- Andrei


More information about the Digitalmars-d mailing list