Memory Safe Programming

[Nick Treleaven]

On Monday, 17 August 2026 at 17:53:22 UTC, Dukc wrote:
> ```D
> module foo;
>
> extern(C) void* malloc(size_t);
> extern(C) void free(void*);
> ```
>
> is now fine but with a default `@safe` will now introduce 
> unsafe functions usable from `@safe` code. Almost everyone 
> considered this unacceptable.
>
> However, simply specifying that external functions with a 
> foreign language linkage would remain `@system` by default has 
> another problem:

The solution is to make declaring a foreign linkage function 
`@safe` a compile-time error.

> the maintainer of the prototypes can be tempted to simply add 
> `@safe:` or `@trusted:` to the top of the declarations to get 
> the now-`@safe` client code to compile again with minimal 
> effort, and once again we have unsafe functions callable from 
> `@safe` code. Walter considered this unacceptable.

In a way it's good if a module is marked `@trusted:`, because 
that is a massive red flag to a reviewer of the code. OTOH 
`@safe:` is a lie if it applies to foreign linkage prototypes, 
because the D compiler cannot check them for memory-safety. D 
prototypes can be `@safe` as they have different linkage from 
`@system` functions.