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?
