D not considered memory safe

[Walter Bright]

On 7/13/2024 10:16 AM, Dennis wrote:
> Not much actual `@safe` code has come from it unfortunately.

That's because the design of it resists @safe requirements.

For a major one, there's `struct elem`:

https://github.com/dlang/dmd/blob/master/compiler/src/dmd/backend/el.d#L69

Note the union in it, which maps pointers on top of non-pointers. This is 
detected as unsafe. And it is unsafe! (But it works.)

Use of `struct elem` permeates the backend.

Then there is the `struct code`:

https://github.com/dlang/dmd/blob/master/compiler/src/dmd/backend/x86/code_x86.d#L299

which relies on `union evc`:

https://github.com/dlang/dmd/blob/master/compiler/src/dmd/backend/code.d#L43

which also "unionizes" pointers and values.

That pretty much covers the backend.

Nevertheless, I still have been creating PRs that replace other unsafe 
constructs, like replacing pointers to arrays with D arrays, and replacing 
pointers to single objects with references. (This is why I wanted the ref DIP 
implemented, but I have to delay using it until the bootstrap compiler supports it.)

The problem with the front end is different. It's problem is the lack of leaves! 
Due to the use of lazy semantic analysis, the compiler is very recursive. You 
can't make one function @safe without simultaneously making every function in 
the cycles @safe. Detouring through @trusted is the only practical path forward 
with that.

Another issue is the use of printf and its buddies. I've proposed ways of making 
printf @safe, but you've objected to them. There are several ways of making it 
@safe, and it's reasonable to do them, but I always run into protests :-)

(To clarify, I am not proposing to make printf itself safe, only making calls to 
printf safe by adjusting its format string, and flagging unsafe use of it.)