On Friday, 22 May 2020 at 17:12:47 UTC, Atila Neves wrote:
[..]
Yes, there's a cost, which is carefully vetting extern(C) and
extern(C++) declarations. The decision came down to finding
this an acceptable trade-off.
How would you feel about a DIP that the only thing it did was
assume all non-extern (D) code was implciti @trusted? And how
about if all such code suddenly became @safe without any vetting
by developers and not even a compiler switch to revert to the old
behavior?
As evidenced by the community outrage, no one but Walter and
(maybe) you are convinced that safe-by-default on function bodies
should imply @safe on non-extern(D) function declarations.
So how about a compromise? We accept a modified version of
DIP1028 in which safe-by-default applies only to function
definitions and extern(D) function declarations. And then there's
a separate compiler switch that changes non-extern (D) function
declarations to be @trusted? If you like this "feature" you're
free to use it on your personal projects, but please don't force
it on everyone who wants @safe to mean anything meaningful.
