C `restrict` keyword in D

[Moritz Maxeiner via Digitalmars-d]

On Monday, 4 September 2017 at 02:43:48 UTC, Uknown wrote:
> On Sunday, 3 September 2017 at 16:55:51 UTC, Moritz Maxeiner 
> wrote:
>> On Sunday, 3 September 2017 at 15:39:58 UTC, Uknown wrote:
>>> On Sunday, 3 September 2017 at 12:59:25 UTC, Moritz Maxeiner 
>>> wrote:
>>>> [...]
>>>> 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).
>>>
>>> Well, I thought about it, I have to agree with you, as far as 
>>> pointers go. There seems to be no simple way in which the 
>>> compiler can safely ensure that the two restrict pointers 
>>> point to the same data. But fir references, it seems trivial.
>>
>> References are just non-null syntax for pointers that take 
>> addresses implicitly on function call. Issues not related to 
>> null that pertain to pointers translate to references, as any 
>> (non-null) pointer can be turned into a reference (and vice 
>> versa):
>>
>> ---
>> void foo(int* a, bool b)
>> {
>>     if (b) bar(a);
>>     else baz(*a);
>> }
>>
>> void bar(int* a) {}
>> void baz(ref int a) { bar(&a); }
>> ---
>
> Yes. But this is what makes them so useful. You don't have to 
> worry about null dereferences.

Indeed, but it also means that - other than null dereferencing - 
pointer issues can by made into reference issues my dereferencing 
a pointer and passing that into a function that takes that 
parameter by reference.

>
>>>
>>> In order to do so, RCArray would have to first annotate it's 
>>> opIndex, opSlice and any other data returning member 
>>> functions with the restrict keyword. e.g.
>>> struct RCArray(T) @safe
>>> {
>>> 	private T[] _payload;
>>> 	/+some other functions needed to implement RCArray 
>>> correctly+/
>>> 	restrict ref T opIndex(size_t i) {
>>> 		//implimentation as usual
>>> 		return _payload[i];
>>> 	}
>>> 	restrict ref T opIndex() {
>>> 		return _payload;
>>> 	}
>>> 	//opSlice and the rest defined similary
>>> }
>>> [...]
>>
>> Note: There's no need to attribute the RCArray template as 
>> @safe (other than for debugging when developing the template). 
>> The compiler will derive it for each member if they are indeed 
>> @safe.
>
> Indeed. I just wrote it to emphasize on the fact that its safe.
>
>> W.r.t. the rest: I don't think treating references as 
>> different from pointers can be done correctly, as any 
>> pointers/references can be interchanged at runtime.
>
> I'm not sure I understand how one could switch between pointers 
> and refs at runtime. Could you please elaborate a bit or link 
> to an example? Thanks.

What I meant (and apparently poorly expressed) is that you can 
turn a pointer into a reference (as long as it's not null) and 
taking the address of a "ref" yields a pointer and as in my `foo` 
example in the above, which path is taken can change at runtime. 
You can, e.g. generate a reference to an object's member without 
the compiler being able to detect it by calculating the 
appropriate pointer and then dereferencing it.