On 22.05.20 03:22, Walter Bright wrote:
This is Obviously A Good Idea. Why would I oppose it?
1. I've been hittin' the crack pipe again.
2. I was secretly convinced, but wanted to save face.
3. I make decisions based on consultation with my astrologer.
4. I am evil.
The sarcasm is not appreciated.
[...]> 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.
2. Annotate useClibrary() as @trusted or @system. While easier, this causes
all benefits to @safe by default to be lost.
In the past you have said repeatedly that the point of @safe is to be
"100% mechanically checkable, not correct by convention" [1]. In other
words, it's supposed to be watertight.
Now you're saying that @safe can have "benefits" without being
watertight. You're even widening an existing hole in @safe to make those
benefits more accessible.
If you have actually given up on a watertight @safe, that's
disappointing for those of us who were with you on a watertight @safe.
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.
Let me get this straight. As a general rule we have: Unsafe stuff is
"supposed to be inconvenient" [2]. But unsafe calls to C functions must
be convenient, because they're so common. So we add an exception to the
rule. And that exception is cool. But making an exception in
@safe-by-default for `extern (C)` prototypes is not cool. Because
exceptions are bad.
Makes sense ... not.
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.
Unlike the catch-and-ignore of your Java analogy, `@safe:` does no harm.
Or rather, it does the same amount of harm that your @safe-by-default
`extern (C)` declarations do. But with the amendment, the idiot
programmer at least has to pull the trigger to shoot their foot off.
You're letting the compiler do it for them.
That @safe even applies to `extern (C)` prototypes is its own issue.
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.
The morale of your Java analogy is that people will find and use the
easy way out. No one is going to add @system to the declarations if the
code already compiles with @safe-by-default.
What is actually accomplished with this amendment if it was implemented?
1. Adds a funky, special case rule. It's better to have simple, easily
understood rules than ones with special cases offering little improvement.
2. Existing, working code breaks.
You can't forgo breakage when making @safe the default. Any template
that is inferred as @system will throw a wrench in your suddenly-@safe
`main`.
3. The most likely code fixes are to just make it compile, absolutely
nothing safety-wise is improved. The added annotations will be a fraud.
And your solution is to let the compiler add the frauds.
D should not encourage "greenwashing" practices like the Java
exception specification engendered. The compiler cannot vet the accuracy
of bodyless C functions, and we'll just have to live with that. The
proposed
amendment does not fix that.
The proposed amendment at least makes the greenwashing visible. With the
DIP as it is, the greenwashing is still there. The compiler just does it
for you. Imagine Java doing catch-and-ignore by itself, just so that the
idiot programmer doesn't have to do it.
It would be better if the greenwashing wasn't even possible. I.e., don't
allow @safe on `extern (C)` prototypes. If that's what you're going for,
great. But you're not, are you?
By the way, I don't think you have acknowledged Steven's idea [3] at
all, yet. Maybe you've missed it. It's completely different from the
"Obviously A Good Idea" amendment you've discussed here.
[1] https://issues.dlang.org/show_bug.cgi?id=14125#c26
[2] https://forum.dlang.org/post/r5hnjo$1j40$1...@digitalmars.com
[3] https://forum.dlang.org/post/r6kvm4$1vq5$1...@digitalmars.com
