C `restrict` keyword in D

[Moritz Maxeiner via Digitalmars-d]

On Sunday, 3 September 2017 at 06:11:10 UTC, Uknown wrote:
> On Sunday, 3 September 2017 at 03:49:21 UTC, Moritz Maxeiner 
> wrote:
>> On Sunday, 3 September 2017 at 03:04:58 UTC, Uknown wrote:
>>> [...]
>>>
>>> void foo(ref RCArray!int arr, ref int val) @safe
>>> {
>>>     {
>>> 	auto copy = arr; //arr's (and copy's) reference counts are 
>>> both 2
>>> 	arr = RCArray!int([]); // There is another owner, so arr
>>> 			       // forgets about the old payload
>>>     } // Last owner of the array ('copy') gets destroyed and 
>>> happily
>>>       // frees the payload.
>>>     val = 3; // Oops.
>>> }
>>>
>>> Here, adding `restrict` to foo's parameters like so :
>>>
>>> void foo(restrict ref RCArray!int arr, restrict ref int val)
>>>
>>> would make the compiler statically enforce the fact that 
>>> neither references are pointing to the same data. This would 
>>> cause an error in main, since arr[0] is from the same block 
>>> of memory as arr.
>>
>> How does the compiler know which member of RCArray!int to 
>> check for pointing to the same memory chunk as val?
>
> If I understand C's version of restrict correctly, the pointers 
> must not refer to the same block. So extending the same here, 
> val should not be allowed to be a reference to any members of 
> RCArray!int.

AFAICT that's not what's needed here for safety, though: RCArray 
will have a member (`data`, `store`, or something like that) 
pointing to the actual elements (usually on the heap). You 
essentially want `val` not to point into the same memory chunk as 
`data` points into, which is different from `val` not to point to 
a member of RCArray.

>
> This does seem to get get more confusing when the heap is 
> involved as a member of a struct.
> e.g.
> [...]

Right, that's essentially what an RCArray does, as well.

> I feel that in this case, the compiler should throw an error, 
> since val would be a reference to a member pointed to by 
> _someArr, which is a member of x. Although, I wonder if such 
> analysis would be feasible? This case is trivial, but there 
> could be more complicated cases.

The main issue I see is that pointers/references can change at 
runtime, so I don't think a static analysis in the compiler can 
cover this in general (which, I think, is also why the C99 
keyword is an optimization hint only).