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

[John Colvin]

On Wednesday, 25 March 2020 at 07:03:16 UTC, Mike Parker wrote:
> This is the feedback thread for the Final Review of DIP 1028, 
> "Make @safe the Default".
[snip]
> https://github.com/dlang/DIPs/blob/5afe088809bed47e45e14c9a90d7e78910ac4054/DIPs/DIP1028.md

I think one detail of the DIP should be amended:

The section making non-D-mangled - e.g. extern(C) - functions 
@safe by default.

Points against:

1) existing extern(C) declarations - including bindings in 
libraries in transitive dependencies etc. - will likely be 
silently wrong in a way that breaks the guarantees of @safe. 
Without careful review and updates, all that code can't be used 
if @safe is a requirement, or nasty memory safety bugs will occur 
that would otherwise not have happened (because @safe without 
this DIP would have caught them).*

2) It now means that one now has to search for extern(C) as well 
as @trusted to find code that might be breaking @safe. Linter 
rules to support correct usage of the language will be created to 
ensure all extern(C) declarations have explicit attributes, to 
avoid the inevitable mistakes that will occur otherwise. This is 
pretty sad, because the compiler can do a better job.

3) It can be quite hard to ascertain whether it's reasonable to 
mark a C function as @trusted or not. The path of least 
resistance shouldn't be towards assuming @safe without 
consideration.

In summary, this invites new bugs and creates new work to avoid 
them.

Suggestions to improve the DIP:

A) non-D-mangled functions should be @system by default,
or
B) the recommendation in the DIP "Interfaces to extern C and C++ 
functions should always be explicitly marked." should be enforced 
by the compiler.


* yes, I know there are many cases where it will be totally fine, 
because no new @safe (inferred or explicit) code is being written 
calling those functions (or any functions relying on attribute 
inference that do call those functions), or because existing 
complicated meta-programming won't spit out new calls in 
unexpected places and accidentally be inferred as @safe. But 
those cases aren't all the important cases.