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

[Walter Bright]

On 3/25/2020 9:57 PM, Jonathan M Davis wrote:
> The line "Interfaces to extern C and C++ functions should always be
> explicitly marked" is pretty vague from the perspective of a spec.

The DIP isn't entirely a spec. When it says "should" it's a recommendation for 
best practice.


> Based on the paragraph above stating that "An unmarked extern (D) function
> will now be considered @safe," I would guess that that means that any
> functions which aren't extern(D) (be they extern(C), extern(C++),
> extern(ObjC) or whatever) would be treated as @system if not marked
> otherwise (just like happens now), but I think that the DIP should be
> explicit about it.

It's pretty clear that declarations would default to @safe. All of them. The 
discussion feedback indicated that this point wasn't confusing.

> There's also the question of declaration vs definition for functions which
> aren't extern(D). It makes no sense for a function declaration which is not
> extern(D) to be treated as @safe by default, because the compiler can't
> guarantee its @safety. However, I don't think that it would be a problem for
> non-extern(D) function definitions, because then the compiler _can_ check
> their @safety. Either way, the DIP should be explicit about what happens
> with declarations and definitions which are not extern(D) - regardless of
> whether declarations and definitions are treated differently.
> 
> I'd also argue that @safe should not be allowed on function declarations
> which are not extern(D), because the compiler can't guarantee their @safety
> (meaning that if an explicit @safety attribute is supplied, it must either
> be @system or @trusted), and allowing @safe on non-extern(D) declarations
> makes it much harder for programmers to grep for @trusted code that could be
> the source of @safety problems. In practice, right now, I'm unaware of
> anyone marking extern(C) declarations as @safe, but if someone did, it could
> be very hard to track down the problem if it were hiding a memory safety
> bug, and given the ease of marking all declarations and definitions in a
> module with @safe via @safe: or @safe {}, it wouldn't surprise me if some
> code bases are accidentally marking extern(C) declarations with @safe right
> now and thus hiding memory safety issues. However, allowing @safe on
> non-extern(D) function _definitions_ should be fine, since then the compiler
> actually is verifying the code. Regardless, much as I think that the DIP
> _should_ make it illegal to mark non-extern(D) declarations as @safe, that
> would arguably be an improvement over what the DIP currently does rather
> than being required for the DIP to actually make sense or be acceptable.

On the other hand,

1. it's a special case inconsistency, which has its own costs and confusion.

2. the compiler cannot verify any extern declarations as being safe, even D
ones. It's always going to be up to the user to annotate them correctly.

3. the extern(C) specifies an ABI, it doesn't say anything about how the
function is implemented, or even which language it is implemented in. A pretty
big chunk of the dmd implementation (80-90%?) is extern(C++)

4. it's trivial to mark a block of C function declarations with @system and
trivial to audit it. I've done it already to a bunch of druntime headers

5. D's separate compilation model relies on extern declarations where source is
not available and safety cannot be machine checked. It's inherent

6. We're just talking about the default. The whole point of @safe being the
default is that it is far and away the most common case, even for C functions.

7. A function having different attributes depending on whether or not a body is
present is surprising behavior

8. annotating "extern(C) void free(void*);" as @safe doesn't make it safe, 
either, again relying on the user

9. what do we do with "nothrow" by default? Say this doesn't apply to 
extern(C++) functions? Is anyone going to remember all these special cases?