DIP1028 - Rationale for accepting as is

[aliak]

First, thank you for the explanation! I have a few observations 
though, mainly that the exception analogy feels like more an 
argument against the DIP than for it. And I also have an 
alternative proposal that might be considered?

On Friday, 22 May 2020 at 01:22:19 UTC, Walter Bright wrote:
> This, of course, was incredibly tedious and annoying. So what 
> happened?
>
> 1. Functions would just do a try-catch(Throwable) and ignore 
> the exceptions.
> Oops.
>
> 2. The Exception Specifications became simply `throws 
> Throwable`. Oops.

This is what happens in swift these days:

func g() /*throws*/ {
   do {
     try f()
   } catch {}
}

But, it's very rare. And passing something like that in code 
review is very difficult and, almost always, the reviewer will 
ask for comments so other people will know why the laziness (if 
it even really was laziness, sometimes it's the right thing to 
do).

Of course the one big difference between exception specifications 
and @safe is the implied importance; @safe is compiler-enforced 
and has the user's trust, exception specifications are human 
guess work of what are the important exceptions and how varied 
they need to be - it's API design - very hard to get right.

The exception specification becoming "throws Exception", while 
highlights the failure of exception specifications, does so with 
a non-dangerous resolution. I.e. you still need to mark your 
function as throwing, and you still need to at least "try" to 
catch the exception. Even a forced "catch(Exception)" is better 
than nothing and shows where problems can be and encourages 
scrutiny.

> How does this relate to safe by default?

That people will use the most convenient solution to get their 
work to compile if the juice is not worth the squeeze?

>
> 1. Go through...
>
> 2. Annotate...safe by default to be lost.
>
> 3. Wrap the call...
>
> 4. Edit clibrary.d and make the first line:
>
>     @safe:

5. Edit clibrary.d and make the first line @trusted: ?

Which brings me to the proposal of making @safe illegal on 
function prototypes. Reason being that @safe stays compiler 
checked. @trusted maintains it's path and value in hunting down 
memory corruption. extern(Anything) functions cannot lie anymore 
about being compiler-checked.

>
> 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.
>
> If it's @safe by default, and then someone chooses to annotate 
> it with @system

Which is the rare case in this scenario right? And 1) there's no 
way to tell if someone made an effort in the case where none are 
marked @system. 2) this is also only for the case of C library 
bindings (reason being that most of my code, and also others' 
code I've seen, has extern(C) functions splattered around various 
D files and not in a dedicated clibrary.d file - is this just me?)

> 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.
>
> 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.
>
> 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.
>
> 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.
>
> And so, I did not incorporate the proposed amendment to the 
> Safe by Default
> DIP.

I think there's a failure to understand why explicit greenwashing 
via a deliberate (possibly code reviewed) addition of @safe: at 
the top is worse than a global implicit greenwashing by the 
compiler, ignoring the rare "feel-good-but-can't-be-sure" 
scenario above where some functions are marked as @system, and 
especially given the premise that programmers are lazy.

Also ... error on @safe prototypes?