Memory Safe Programming

[Dukc]

On Sunday, 16 August 2026 at 08:50:38 UTC, GB wrote:
> It's primarly about memory safety in C, but D gets a mention in 
> the Appendix I.
>
> But it raises the question: why isn't @safe not the default in 
> D?

There actually was [a decision to make it the default, which was 
soon 
reverted](https://github.com/dlang/DIPs/blob/master/DIPs/rejected/DIP1028.md). Pretty much everybody was (and probably is, over an edition switch since we now have those) willing to go on with that.

There's an unfortunate gotcha though, which ended up killing the 
DIP. Consider a module naively declaring some C or C++ functions, 
something like

```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 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.

I wonder though if the situation has now changed though. When the 
DIP was written, there would have been surge of compilation 
errors from previously `@system` code becoming `@safe` overnight, 
and therefore pressure to cut corners with the measures to get 
code compiling again. But today, it wouldn't be the case since 
the new default would only apply to code under a new edition. 
Existing code would stay at older editions until reannotated to 
conform, so there would be no breakage to deal with.

Walter, if you happen to read this how does this sound?