D not considered memory safe

[Timon Gehr]

On 7/13/24 14:37, aberba wrote:
> On Thursday, 11 July 2024 at 16:26:59 UTC, Walter Bright wrote:
>> On 7/9/2024 8:58 AM, Nick Treleaven wrote:
>>> [...]
>>
>> That's right. Converting an entire program to @safe can be done 
>> successfully by doing it incrementally, getting it to pass its test 
>> suite at each step. The way to do it incrementally is to start by 
>> labeling each function @trusted, then making them @safe one by one.
>>
>> I've done this, it works.
>>
>> And, as you observe, grepping for "@trusted" makes for a builtin-in 
>> TODO list!
> 
> 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.