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.
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
}
void main() @safe
{
RCArray!int my_array;
...
auto t = my_array[0];//error: my_array.opIndex(0) is defined as
restrict
//This essentialy prevents a second reference from existing in
the same scope
foo(arr, arr[0]);
//error: call to foo introduces `restrict` data from the same
container
//into the scope of foo
}
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;//No longer an issue!
}
This is now no longer like the C99 keyword in behaviour, but on
the bright side, with one annotation to the return types, RCArray
suddenly doesn't need to worry about escaped references. Also, no
modifications would be needed to the foo function.
This is potentially useful for other owning container types. The
compiler could still use the information gainer from the restrict
annotation for optimizations, although such optimizations would
be much less aggressive than in C.
Coming back to pointers, the only way I can see (short of
bringing Rust's borrow checker to D) is to add additional
annotations to function return values. The problem comes with
code like this :
int * foo() @safe
{
static int[1] data;
return &data[0];
}
void main()
{
int * restrict p1 = foo();
int * restrict p2 = foo();//Should be error, but the
compiler can't figure
//this out without further
annotations
}
