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?
