DIP1028 - Rationale for accepting as is

[ag0aep6g]

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- at 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