C `restrict` keyword in D

[Uknown via Digitalmars-d]

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.

This does seem to get get more confusing when the heap is 
involved as a member of a struct.
e.g.
void main() @safe
{
	struct HeapAsMember {
		int* _someArr;
	}
	HeapAsMember x;
	x._someArr = new int;
	void foo(restrict ref HeapAsMember x, restrict ref int val) @safe
	{
		x._someArr = new int;
		val = 0;
	}
	foo(x, x._someArr[0]);
}
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.