On Tuesday, 15 November 2022 at 13:16:18 UTC, Paul Backus wrote:
D's safety model is the same. In `@safe` code, D will reject anything that the compiler cannot say for sure is memory safe. However, unlike in Rust, `@safe` is not the default in D, so you must mark your code as `@safe` manually if you want to benefit from these checks.
I specifically asked for Ali's opinion. Because the context is that the compiler couldn't catch a memory safety bug in the code that was annotated as @safe (but without -dip1000) and Ali commented that "the compiler cannot do anything about it in all cases and we wouldn't want it to spend infinite amount of time to try to determine everything". This sounds like he justifies the compiler's failure and accepts this as something normal.
The https://dlang.org/spec/memory-safe-d.html page also provides a rather vague statement: "@safe functions have a number of restrictions on what they may do and are intended to disallow operations that may cause memory corruption". Which kinda means that it makes some effort to catch some memory safety bugs. This weasel language isn't very reassuring, compared to a very clear Rust documentation.
