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

[Arine]

On Wednesday, 25 March 2020 at 08:37:53 UTC, Walter Bright wrote:
> Since @safe will now be the default, all extern functions will 
> be @safe. It shouldn't be necessary to enumerate what 
> declarations are covered by this. It would only be necessary to 
> enumerate declarations which would not be.

It doesn't make sense for C and C++ functions to be @safe. They 
have no @safe mechanize to ensure it is actually @safe.

> Interfaces to extern C and C++ functions should always be 
> explicitly marked.

Is this just another "best practice" to accommodate the breaking 
change this DIP will provide without actually providing a real 
world solution to the problem? Saying you *should* do this 
doesn't address the actual problem of the breaking changes.

Extern C/C++ functions **shouldn't** default to @safe, it doesn't 
make sense as those languages don't have a @safe feature. You 
can't make any of the same arguments for C/C++ that you can for 
D, that most C/C++ code is @safe so it should be the default 
there as well?

If this is the best practice, then it would be better for the 
compiler to simply enforce it. Any C/C++ bindings are going to 
now be wrongly labelled as @safe otherwise. People aren't going 
to get an error that they can fix to update, so D code that uses 
these libraries are also going to be @safe now too when they 
actually aren't. I can guarantee you any new C/C++ bindings after 
this change won't be using this "best practice", as it isn't 
obvious and it goes directly against how it behaved for the last 
what 20+ years (and any documentation of how to create C/C++ 
bindings).