D not considered memory safe

[Quirin Schroll]

On Thursday, 11 July 2024 at 16:16:25 UTC, Walter Bright wrote:
> On 7/10/2024 11:31 PM, Richard (Rikki) Andrew Cattermole wrote:
>> Yeah I get that, but that is a major problem for things like 
>> std.algorithm.
>> 
>> There will be situations without a migration path forward.
>
> Pass @trusted arguments to the templates.
>
> The truth is about every piece of existing code not already 
> annotated is going to fail to compile with safe-by-default. 
> That's been my experience, at least.
>
> The migration path is to mark the stuff with @trusted. You can 
> see that in the dmd source code.

My bet is annotating things `@trusted` on a large basis is going 
to end up an eternal makeshift.

My solution is you annotate modules. If you’re a library writer, 
yes, you’re still out of luck. But as an application writer, if 
you write `default @safe module m;` the module’s default is 
`@safe` now. Defaults don’t touch templates and other inferred 
functions, but they do (meaningfully) touch interfaces and 
higher-order functions. If you’re developing an application and 
some interface or higher-order function doesn’t work for you 
after adding some annotation, well, it’s your code. Change it to 
your needs.

For existing libraries that aren’t annotated, the situation is 
worse as users may rely on them being `@system`, e.g. because you 
(logically) can’t implement a `@safe` interface method with a 
`@system` function. For a higher-order function in a library 
without attributes, if the function is relatively-safe (i.e. 
calls with `@safe` delegate are safe), you can write a `@trusted` 
wrapper that just casts the original:

```d
import noattrib;
alias hof = noattrib.hof;
auto hof(void delegate() @safe callback) @trusted => 
noattrib.hof(callback);
```