Discussion Thread: DIP 1028--Make @safe the Default--Final Review

[Steven Schveighoffer]

On 3/25/20 10:10 AM, Steven Schveighoffer wrote:
> In response to Walter's response to ag*, I would say that there is a 
> fatal problem with automatically allowing extern(C) function prototypes 
> (and really, anything that does not mangle @safe) to be default @safe.
> 
> The reason is simple -- the change is silent and automatically marks 
> everything @safe that has not been checked.
> 
> I would argue that if the compiler is going to make things @safe by 
> default, then things that are not marked and are not @safe should not 
> compile AT ALL COSTS. Otherwise the value of @safe is completely lost.
> 
> The DIP should be rejected IMO unless all functions with no mechanism to 
> mangle @safe into the name (e.g. extern(C), extern(C++), etc) that have 
> no implementation are either:
> 
> a) required to be marked, or
> b) default @system.
> 
> Everything else in the DIP is possibly annoying to deal with but at 
> least doesn't silently destroy the meaning of @safe.
> 
> I will note that I support the notion of @safe by default. I would be in 
> favor of the DIP as long as this fatal flaw is not included.

I thought of a third option that could work:

When an extern(C) @safe function is compiled, produce 2 symbols that 
point at the same function text, one that is the normal extern(C) 
function symbol name (_foo), and one that is mangled with something like 
e.g. _dsafe_foo.

When there is an extern(C) @safe prototype, only look for the _dsafe_foo 
version. If there is an extern(C) @trusted or or @system prototype, then 
look for the normal _foo symbol.

What does this accomplish?

1. you can keep @safe by default extern(C) functions, as they now will 
not link if the real function is @system or built in something other than D.
2. @trusted "overrides" still work. In other words the function is 
implemented in C but can technically be @trusted because it doesn't 
involve memory safety problems.
3. Calls from other languages that bind to C still work. In other words, 
you can still call foo from C/C++ through the normal C symbol.
4. Any changes to the actual implementation that cause the prototype to 
be @trusted or @system will now fail to link as the _dsafe_foo symbol 
goes away.

I don't know how this might work for extern(C++), and I'm also not sure 
how the symbol emission works, but I feel like this should be possible. 
It would be a benefit even if we don't make @safe the default for extern(C).

-Steve