D not considered memory safe

[Walter Bright]

On 7/13/2024 6:09 AM, Timon Gehr wrote:
>> This to me is the most sensible way to go about it.
> 
> It's not. You'll quickly lose track of the 3 kinds of `@trusted` functions:
> 
> - @trusted functions that should be @safe
> - @trusted functions that should be @trusted
> - @trusted functions that must be @system
> 
> This is plain safewashing.

Not if the @trusted functions have a safe interface (though the compiler cannot 
check the interface for safety, it is up to the programmer).


> If you want incremental safety in the current language, you have to start at the 
> leaves, and put your TODO's in comments.

In my efforts to make the front end @safe, that approach does not work. The 
problem is that the front end flow graph is cyclical. There aren't many leaves, 
and a lot of those leaves in the front end have been marked as @safe.


> OpenD has an interesting approach towards default safety. They enabled a large 
> fraction of safety checks in functions without a safety annotation. To disable 
> them, explicit @system is required. This way you get linting benefits even 
> without already ensuring full memory safety guarantees.

It's an interesting approach, but certainly half-baked. How does one decide 
which safety checks are to be included?


> Anyway, there are many language-assisted ways to make incremental @safe 
> migration work (some would require only minimal changes to the compiler), but I 
> think slapping @trusted everywhere will not do anything to improve the 
> perceptions about D's memory safety.

You've often been quite adamant about memory safety being 100% (and I tend to 
appreciate that point of view and am in agreement with it). A half-baked 
approach won't help, either.

With the @trusted approach, I'll often change it to @safe, fix what I can, then 
put it back to @trusted.