On Friday, 22 May 2020 at 05:37:55 UTC, Walter Bright wrote:
On 5/21/2020 8:36 PM, Paul Backus wrote:
Something ought to be done to prevent this. It doesn't have to
be the exact
proposal from the discussion thread, but doing nothing and
allowing widespread
silent breakage cannot possibly be the best solution.
I can see that happening. A simple example would be:
extern (C) void free(void* p);
...
free(p);
free(p);
The thing is, you are no worse off than now. If free() can be
misused by calling it from system code, it can be misused by
calling it from safe code.
There's no way the compiler can detect this. If you annotate
it, you'll just have to annotate it correctly. Forcing an
annotation just means slapping @safe: at the beginning of the
file and moving on - it's not going to help.
Currently, if I want to use @safe correctly, all I need to do is
annotate my code with @safe and fix any compile errors that arise
as a result.
With -preview=safedefault enabled, if I want to use @safe
correctly, I am now required to *manually* review every extern
function declaration in every module of every dependency of my
program to make sure that they are explicitly annotated. If I do
not do this, I risk introducing silent safety violations to my
program.
You are correct that in both cases, I can run into trouble if
@safe is misused. Nonetheless, I submit to you that I am worse
off in the second case than in the first.
The compiler cannot be expected to guard against deliberate
misuse, but it *can* be expected to give us the necessary tools
to use @safe correctly. The current implementation of DIP 1028
does not do so.
