DIP1028 - Rationale for accepting as is

[Gregory]

On Friday, 22 May 2020 at 01:22:19 UTC, Walter Bright wrote:
> Consider the common (because that's how D started out) case of:
>
> ----- clibrary.d --------
>
>     T massage_data(... many parameters ...);
>     ... 200 more such declarations ...
>
> ----- app.d ----------
>
>     import clibrary;
>
>     void useClibrary( ... parameters ...) {
>         massage_data(parameters);
>     }
>
> ---------------------
>
> This code, today, does not use annotations and it works. It's 
> been working
> for a long time. Now, we implement the amendment, and it stops 
> compiling
> because useClibrary is @safe and massage_data is @system. The 
> user is faced
> with the following alternatives:

Why are you assuming that the only thing wrong with useClibrary() 
is that it would use a C declaration that is @system? All @system 
code I've written is @system and wouldn't compile to @safe even 
if extern(C) declarations are wrongly annotated as @safe.

What if app uses core.stdc? All those functions have already been 
annotated as @system. Any code that uses the C stdlib is going to 
break right now anyways.

What's stopping someone from just as easily slapping @trusted: at 
the top of app.d? Since there are going to be more issues than 
simply calling extern(C) functions.

I find it odd also that you are using one of the rationales 
against making @safe the default (that code will break and lazy 
solutions will be employed to make them work again), as a means 
to make @safe, less memory safe.