D not considered memory safe

[Walter Bright]

I appreciate your help with this!

On 7/19/2024 12:43 PM, Dennis wrote:
> 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'.

The hard problems aren't being tackled, like toChars(). One would think it would 
be a leaf, but it isn't. It can call semantic(), semantic() can call the parser, 
and round and round it goes.

There's no place to start.

I haven't found a better way. You saw the problems I had with pretregs in the 
backend. I finally had to bite the bullet and do a very large PR. And that was 
simple to do, though very tedious. @safe changes need re-engineering, not just 
query-search-replace.

I've done similar things in the past. What works is doing things incrementally, 
passing the test suite with each increment. What doesn't work is do it all at once.


> 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.

That's one reason to switch to parameters, but there's another: make the 
compiler "stateless" so it can be a library.

 > (though with the bootstrap compiler situation, its usefulness looks very far 
away).

I don't know why the bootstrap compiler needs to be so old? Back in the olden 
daze of my compiler, the previous release was the bootstrap version!