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

[Joseph Rushton Wakeling]

On Sunday, 5 April 2020 at 09:12:21 UTC, Walter Bright wrote:
> Extern declarations are the USER making promises. Even with 
> extern (D), the return type isn't mangled into the name. The 
> User has to get it right.

Yes but :-)

The question is whether the language defaults help the user make 
the _right_ choices.  If the easy thing to do is to do nothing -- 
not add any attribute -- is it more likely that this will be a 
correct choice, or a false promise?

I'm actually starting to think that we're getting the idea of 
`@safe` back to front in this discussion.  As jmh530 pointed out 
earlier 
<https://forum.dlang.org/post/zxwazhgynudymqyueeyy@forum.dlang.org>, `@safe` is not a guarantee that the function is memory-safe: it's a request that the compiler validate that certain potentially-unsafe operations are not performed within the function body.

BY DEFINITION those checks cannot be performed on functions where 
we do not have the body.

So even if we ask for the checks of `@safe` to be on by default, 
there is nothing for them to validate in the case of external 
functions where we only have the signature.

So it falls out quite naturally for the compiler to say here, "I 
can't validate this, so you have to tell me explicitly whether it 
is `@system` or `@trusted`".  (Or perhaps to assume `@system` 
until explicitly told otherwise.)

The one exception would be external D functions where the 
mangling tells us they are `@safe`, where it would be reasonable 
to assume that those were checked when the library concerned was 
compiled.

(This is by the way exactly what jmh530 already said, but I 
thought I'd emphasize it:-)