DIP1028 - Rationale for accepting as is

[Timon Gehr]

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.

5. You are backwards-rationalizing a wrong intuition that is based on 
experiences that are not actually analogous. You are ignoring feedback 
given by many people around you because that worked out well for you in 
the past.

I know that you had many interactions with large groups of ignorant 
people who thought that you would never be able to pull off a certain 
thing. This is not one of those cases. I understand the appeal, but the 
backlash really should not encourage you to soldier on this time.

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

First do 2, then, over time, do 1. If having the @safe tag and no 
@trusted code is important to you, aim to replace the C code with 
something you can automatically verify, by slowly porting it over to D.

> this causes all benefits to @safe by default to be lost. 

Absolutely not. Greenwashing causes the benefits of certification to be 
lost. Honesty does not. The value of @safe code is what it is because 
there is code that can't be @safe.

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

They should know to put @trusted instead of @safe, and the compiler 
should enforce it. Also, why do those people speak for everyone else? 
They don't speak for me.

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

If it has @safe:/@trusted: at the top at least you know they were aware 
what they were doing.
Also, what about if it has @trusted: at the top and some @system 
annotations here and there? Did they not try?

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

What about the funky special case rule that the compiler is responsible 
for memory safety of @safe code except in this one weird special case?

> 2. Existing, working code breaks.
> ...

Making @safe the default is bound to break code. It's bad enough that 
code will break. Avoiding part of that code breakage is no justification 
for breaking @safe.

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

It's vastly better to have some fraudulent annotations in some projects 
than a fraudulent compiler compiling all projects. Do you really want to 
put the responsibility for the memory safety of random C libraries on 
the compiler developers?

> D should not encourage "greenwashing" practices like the Java
> exception specification engendered.

So your argument is that you don't want D programmers to do have to do 
the dirty work of greenwashing. Therefore the compiler will implicitly 
greenwash for them? What about the programmers who actually want to do 
the right thing and don't want the compiler to implicitly greenwash C 
libraries for them?

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

@trusted is the fix.

> And so, I did not incorporate the proposed amendment to the Safe by Default
> DIP.

Which (so far) is a harmless mistake with an easy fix.