DIP1028 - Rationale for accepting as is

[Paul Backus]

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.