D not considered memory safe

[Paolo Invernizzi]

On Saturday, 13 July 2024 at 13:09:14 UTC, Timon Gehr wrote:
> On 7/13/24 14:37, aberba wrote:
>> On Thursday, 11 July 2024 at 16:26:59 UTC, Walter Bright 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.
>
> If you want incremental safety in the current language, you 
> have to start at the leaves, and put your TODO's in comments.
>
> 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.
>
> 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.

I would add one point, Walter wrote in his original port:

"In fact, I've been doing just that. Adding @safe: at the top, 
and then everything that fails to compile gets marked @trusted. 
****Eventually****, refactor the code as time permits."

Ouch!