D not considered memory safe

[Walter Bright]

On 7/13/2024 2:46 PM, Timon Gehr wrote:
> Well, your suggestion was to put @trusted _everywhere_, not only on functions 
> with a safe interface. As Dennis points out, it seems that is exactly what 
> happened in some instances.

That is correct.

> Anyway, `@trusted` indicates that whoever put it there reviewed the 
> implementation for memory safety. This makes this approach impractical.

You could call it unwise, or a footgun, or introducing technical debt. But it is 
practical.

If a surgeon wants to fix a man's heart, first he's going to make things worse 
by slicing him open like a side of beef.

If a mechanic wants to rebuilt an engine, first he has to dismantle a fair chunk 
of the car, making things worse.


> The solution is to remove the unsafe constructs and then mark everything safe in 
> one go. The compiler currently cannot assist with this very well, but it is easy 
> to do. It should just have a way to enable non-transitive safety checks.

In my experience with large, complex programs, cyclical program flow, that is 
not practical. I wish it was practical.


> In a data-driven way. They enabled the checks that do not cause too much pain to 
> users. OpenD is a big monorepository with DMD, LDC, and most of the packages 
> that people actually use, so breaking changes actually require breakage to be 
> fixed as well.

I also incrementally fix @safe issues, by making a function temporarily @safe, 
and fixing what I can. But that does not solve the cyclical dependency problems.


> Anyway, non-transitive checks can be a useful tool for all function attributes, 
> and they have the benefit of not over-specifying their guarantees. This can even 
> be done with pragmas. I implemented a simple pragma to (non-transitively) error 
> out on implicit GC allocations, and it was helpful for performance optimization.

An easier way is just add `@nogc:`, fix all the errors you need to, then remove it.


> Well, if the goal is incremental migration to `@safe`, a process of enabling 
> non-transitive safety checks on a function-by-function basis and then later 
> making it transitive is much more baked than random application of @trusted, and 
> it completely bypasses any issues with big cyclic call graphs.

There is a way:

1. add @safe:

2. fix what you can

3. remove @safe:

No new features required.