> but by simply ignoring that possibility via 'restrict',
If you deceive the compiler like that, it is entitled to hand you a broken executable :-/
Besides, I forgot to mention that D immutable data is inherently thread safe, no synchronization required. And you can have as many live references to it as you like.
Immutable data is part of D's support for functional programming.
restrict is so rarely used that clang has had open code generation bugs for years. Rust would like to use its non-aliasing guarantees to generate better code, but clang is unable to reliably generate correct code.
So even if you manage to reason correctly around `restrict` in C, you can't count on the compiler to translate your code correctly.
GCC also had bugs around restrict, but I don't know about their current status.
I haven't found the compiler ever optimizing something different because of constness. The various escape hatches means that it is really hard for the optimizing compiler to make certain assumptions, especially if it's connected to something with external linkage. A function with a const struct arg that you never take the address of? compiler emits memcpy!
You might be right but if it's just a technicality and in practice nobody uses restrict the way you said, would anyone care about the theoretical superiority of C? I'm sure some would, but they wouldn't be the majority.
If you deceive the compiler like that, it is entitled to hand you a broken executable :-/
Besides, I forgot to mention that D immutable data is inherently thread safe, no synchronization required. And you can have as many live references to it as you like.
Immutable data is part of D's support for functional programming.