Greenwashing

[Jonathan M Davis]

On Wednesday, May 27, 2020 5:57:00 PM MDT Meta via Digitalmars-d wrote:
> On Wednesday, 27 May 2020 at 18:50:50 UTC, Jonathan M Davis wrote:
> > Based on some of Walter's comments, it also sounds like he
> > intends to make nothrow the default in another DIP, which is
> > also a terrible idea. I'm increasingly worried about the future
> > of D with some of where these DIPs are going.
> >
> > - Jonathan M Davis
>
> What's wrong with nothrow by default? Probably 97% of code
> doesn't need to throw exceptions.

If anything, I would say the opposite.

In general, exceptions are by far the best way to deal with error conditions
that we have. They clean up code considerably and make it much harder for
error conditions to be ignored or eaten. Alternatives such as error code are
terrible in comparison. We do end up with far less code being able to be
nothrow in D than we should because of how autodecoding works, but it's
still the case that _way_ more than 97% of the code out there is going to
potentially throw exceptions - especially in applications that have to deal
with users and/or the network. Propagating error conditions without
exceptions gets disgusting fast.

There's no question that there is code that cannot afford the extra cost of
exception handling and has to do something else, but it's much more
error-prone and isn't the norm for programs in general. And of course, in
some cases, exceptions just plain don't make sense (e.g. the fact that
std.utf.validate throws instead of returning bool is terrible), so it's not
like they're always the appropriate solution or used correctly. However, in
general, they most definitely should be the default for how your typical
application deals with error conditions. Anything else leads to far more
bugs. I would have thought that the experience of the programming community
at large at this point would make that pretty clear. Exceptions are by no
means perfect, but for the general case, they're the best way that we have
to cleanly propagate error conditions and avoid having error conditions be
ignored or lost.

Having nothrow be the default would encourage people to not use exceptions
(leading to worse code in general) and would result in a _lot_ more
attributes being needed on the code that does use exceptions. Certainly, I
know that for the libraries and applications that I've worked on for most of
my career (be it in D or some other language), if nothrow were the default,
those libraries and applications would have to be marking throw all over the
place (which is in fact basically what happens in Java, though they have
they extra annoyance of having to mark _which_ exception types can be
thrown, which has proven to be a terrible idea and which we fortunately have
avoided in D).

I think that it's great that we have nothrow for those cases where it's
appropriate, but I don't think that it makes sense at all to assume that
that's the _normal_ situation.

In any case, when the topic has come up before, plenty of people have raised
similar complaints to mine, so if/when Walter puts forth a DIP proposing
nothrow to be the default as I think that he's planning on doing, I expect
that he'll get quite a few dissenting opinions on it - likely far more than
for making @safe the default. Of course, since he won't listen when pretty
much everyone else disagrees with him on what to do with extern(C) with
@safe being the default, who knows how well _that_ will go...

- Jonathan M Davis