> in fact it helps because it allows compilers to turn it a trap without requiring it on weak platforms

The "shared xor mutable" rule in Rust also helps the compiler a lot. It basically allows it to automatically insert `restrict` everywhere. The resulting IR is easier to auto-vectorize and you don't need to micro-optimize so often (although, sometimes you do when it comes to eliminating bound checks or stack copies)

> Restrict is certainly dangerous, but also rarely used and a clear warning sign, compare it to "unsafe".

It's NOT a clear warning sign, compared to `unsafe`. To call an unsafe function, the caller needs to explicitly enter an `unsafe` block. But calling a `restrict` function looks just like any normal function call. It's easy to miss an a code review or when upgrading the library that provides the function. That the problem with C and C++, really. The `unsafe` distinction is too useful to omit.

This happens a lot in discussion about programming complexity. What you are doing is changing the original problem to a much simpler one.

Consider a parsing function parse(string) -> Option<Object>

This is the original problem, "Write a parsing function that may or may not return Object"

What a lot of people do is they sidetrack this problem and solve a much "simpler problem". They instead write parse(string) -> Object

Which "appears" to be simpler but when you probe further, they handwave the "Option" part to just, "well it just crashes and die".

This is the same problem with exceptions, a function "appears" to be simple: parse(string) -> Object but you don't see the myriads of exceptions that will get thrown by the function.

This is a line of thinking I used to see commonly when dynamic typing was all the rage. I think the difference comes from people who view primarily work on projects where they are the sole engineer vs ones where they work n+1 other engineers.

"just add assertions" only works if you can also sit on the shoulder of everyone else who is touching the code, otherwise all it takes is for someone to come back from vacation, missing the refactor, to push some code that causes a NULL pointer dereference in an esoteric branch in a month. I'd rather the compiler just catch it.

Furthermore, expressive type systems are about communcation. The contracts between functions. Your CPU doesn't case about types - types are for humans. IMO you have simply moved the complexity from the language into my brain.