DIP1028 - Rationale for accepting as is

[Bruce Carneal]

On Friday, 22 May 2020 at 01:22:19 UTC, Walter Bright wrote:
> I have made these points before, but I'll summarize them here
> for convenient referral.
>

<big snip> of material indicating, among other things, that even 
really good programmers can screw up when it comes to language 
design now and then.  Ahem.
Continuing...

>
> How does this relate to safe by default?
>
> 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:
>
> 1. Go through 200 functions in clibrary.d and determine which 
> are @safe
> and which are @system. This is what we want them to do. We try 
> to motivate
> this with compiler error messages. Unfortunately, this is both 
> tedious and
> thoroughly impractical, as our poor user Will Not Know which 
> are safe and
> which are system. We can correctly annotate core.stdc.stdio 
> because I know
> those functions intimately. This is not true for other system C 
> APIs, and
> even less true for some third party C library we're trying to 
> interface to.

Agree completely.   Annotating C code correctly can be very 
difficult.  This argues against defaulting such code to @safe.

>
> 2. Annotate useClibrary() as @trusted or @system. While easier, 
> this causes
> all benefits to @safe by default to be lost.

No.  The benefit of @safe is actually having machine checkable 
@safety.

>
> 3. Wrap the call to massage_data() with:
>
>     () @trusted { massage_data(parameters); } ();
>
> If there are a lot of calls to clibrary, this is going to look 
> pretty awful.
> Nobody likes writing or reading such ugly code. It's ok here 
> and there, but
> not as a general thing.

Yeah, this is ugly.

>
> 4. Edit clibrary.d and make the first line:
>
>     @safe:
>
> I submit that, just like with Java, Option 4 is what people 
> will reach for,
> nearly every time. I've had some private conversations where 
> people admitted
> this was what they'd do. People who knew it was wrong to do 
> that.

The DIP gives us 4), the worst case, by default.  Anywhere and 
everywhere a C lib shows up it gives us 4), automatically.

>
> If it's @safe by default, and then someone chooses to annotate 
> it with @system
> here and there, I'd feel a lot more confident about the 
> accuracy of the code
> annotations than if it just had @safe: at the top. At least 
> they tried.
>

So @safe is to be based on a feeling?  At least they *tried*?  
This is a key point of disagreement.  Machine checked @safety is 
something.  Human hand waving @safety is not.

It is bizarre that no one has been able to get you to see the 
contradiction with your earlier writings on safety (big fan there 
btw). C's biggest blunder?  Yeah, well, all the bugs engendered 
by that blunder and many many more are now to be considered @safe 
by default. What the heck?

Finally, Atila, can you shed any light on this?  Where do you 
stand?  Why did it seem like a good idea to withhold your veto?