Challenge: write a reference counted slice that works as much as possible like a built-in slice

Timon Gehr timon.gehr at gmx.ch
Sat Nov 13 03:13:46 UTC 2021


On 13.11.21 01:29, Paul Backus wrote:
> On Friday, 12 November 2021 at 22:09:28 UTC, Andrei Alexandrescu wrote:
>> On 2021-11-12 16:14, Timon Gehr wrote:
>>> You still need language support. Reaching mutable data through an 
>>> immutable pointer violates transitivity assumptions.
>>
>> Indeed, but not indirectly. You can soundly access a pointer to 
>> mutable data if you use the immutable pointer as a key in a global 
>> hashtable.
> 
> I guess the question reduces to: what is the simplest thing you can do 
> to a pointer that will make the compiler forget its provenance?
> 
> Adding an offset is clearly not enough. Casting it to an integer, taking 
> its hash, and using that hash to look up a value in an associative array 
> is probably *more* than enough. Is there something in between that's 
> "just right"?
> 
> One possibility is casting the pointer to an integer, and then 
> immediately casting it back:
> 
>      immutable(int)* p;
>      size_t n = cast(size_t) (p - 1);
>      int* q = cast(int*) n;
>      *q = 123;
> 
> Assume we know, somehow, that the memory location pointed by q is 
> allocated and contains a mutable int. Does the mutation in the final 
> line have undefined behavior?
> 
> The answer depends on whether integers have provenance or not--a 
> question which remains unsettled in the world of C and C++. [1] If we 
> decide that integers should *not* have provenance in D, then the above 
> code is valid, and we do not need to add any new features to the type 
> system to support it.
> ...

It may also depend on whether you are in a pure function or not.


More information about the Digitalmars-d mailing list