> aliasing can’t happen unless both references are read only
Other languages have long had aliasing, Fortran for one. C and C++ have the restrict keyword though obviously it's a programmer guarantee there and is less safe, since if the user of the function does pass the same memory ref offset for e.g. the optimisation is not safe.
I'd say in name only given that there were numerous aliasing bugs in llvm that only became visible when Rust tried to leverage it. I suspect similar pitfalls exist in every single C/C++ compiler because the rules for restrict are not only difficult to understand for use but also difficult to implement correctly.
Left a comment on another reply, but as I said there, there's a big difference in approach because restrict usually only gets sprinkled in on very few functions, but it doesn't mean it's not used.
It's not used much in a sense that it's applied to very few functions, but it is well known and widely used in limited circumstances. The bugs in LLVM (and GCC) are basically because Rust is using aliasing much more widely than it ever has been in most C programs.
Take for e.g. this:
void add(double *A, double *B, double *C, int N) {
for(int i = 0; i < N; i++) {
C[i] = A[i] + B[i];
}
}
You generally wouldn't find many C developers sprinkling restrict in on functions like this, since that function could be useful to someone using add on two overlapping arrays.
On the other hand, someone writing a ODE solver in a scientific code might write a function like this, where it would never make sense for the memory locations to overlap:
void RHS(double* restrict x, double* restrict xdot, int N, double dt) {
for(int i = 0; i < N; i++) {
xdot[i] = -x[i]/dt;
}
}
In those sorts of circumstances, it's one of the first performance optimisations you might reach for in your C/C++ toolkit, before starting to look at for e.g. parallelism. It's been in every simulation or mathematical code base I've worked on in 10+ years at various different academic institutions and industry companies.
It's generally true that C/C++ code rarely if ever uses restrict & that Rust was the first to actually put any real pressure on those code paths and once it was found it took over a year to fix and it's incorrect to state that the miscompilation was only in code patterns that would only exist in Rust.
In the areas I've worked these sorts of cases would have been picked up by tests, and especially checking for correctness of output between different optimisation levels. But I can concede that that's perhaps not the standard sort of workflow for many C/C++ developers.
You should be able to remove `restrict` in any valid C program and still compile it and run it with the same result, no? Adding `restrict` can make otherwise valid code UB if there's aliasing, but the reverse shouldn't ever appply.
Other languages have long had aliasing, Fortran for one. C and C++ have the restrict keyword though obviously it's a programmer guarantee there and is less safe, since if the user of the function does pass the same memory ref offset for e.g. the optimisation is not safe.