Vision for the D language - stabilizing complexity?

Lodovico Giaretta via Digitalmars-d digitalmars-d at puremagic.com
Tue Jul 12 11:53:31 PDT 2016


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.


More information about the Digitalmars-d mailing list