Currently applying an @restrict attribute to a slice argument results in something like this from ldc:
Attribute 'noalias' applied to incompatible type! i16 ({ i64, i16* })* ...
Might this be upgraded to match gdc's current behavior on godbolt? (allow @restrict for both pointers and slices) I don't see a downside apart from the, hopefully modest, work required to get it in place. On the upside, it would be nice to be able to use @restrict with somewhat safer, idiomatic code.
For reference, I've observed that @restrict helps the auto vectorizer in both gdc and ldc. At a minimum it eliminates all the "lets check if these are overlapping" code. It may help keep the auto-vectorizers engaged with more involved kernels. I have nothing to report on that yet but it makes sense as the costs are lowered somewhat and the analysis is simplified.
Assuming @restrict applies to slices in the future, the idiomatic form might be to attach @restrict to output buffer arguments passed to @trusted routines. As you'd expect, both compilers "do the right thing" when read-only source arguments remain unadorned.