D not considered memory safe

[Dennis]

On Friday, 19 July 2024 at 18:19:38 UTC, Walter Bright wrote:
> In my experience with large, complex programs, cyclical program 
> flow, that is not practical. I wish it was practical.

I assume you're mostly referring to dmd. I've also been 
incrementally improving dmd's own safety over the years, but by 
working bottom up, without marking functions with unsafe 
interfaces `@trusted`. How do the strategies compare? One 
approximation would be to simply count additions / deletions of 
`@safe`, `@system` and `@trusted` in our commits over the last 5 
years:

```
 From me:
   @safe:    +1048 -245
   @trusted:  +109 -181
   @system:   +166 -302

 From you:
   @safe:     +315 -142
   @trusted: +1331  -46
   @system:   +242  -14
```

(Generated by 
https://gist.github.com/dkorpel/666aa59e0b910713f614382f563e89b4 
and dmd-master today)

Take these numbers with a grain of salt: this doesn't analyze the 
scope and actual impact of those attributes of course. However, 
it's hard to believe mass-applying `@trusted` on functions is 
'the only practical way'.

In my experience, the main obstacles of a `@safe` dmd are 
abundant use of `__gshared` and C-strings. That's why I 
appreciate your pull requests where you refactor globals into 
parameters, those improve the `@safe` situation for real. The DIP 
idea to make printf's interface `@safe` is also a step in the 
right direction because `error()` calls are everywhere. (though 
with the bootstrap compiler situation, its usefulness looks very 
far away).