What is the point of nothrow?

[Jonathan M Davis]

On Monday, June 18, 2018 15:22:48 wjoe via Digitalmars-d-learn wrote:
> On Saturday, 16 June 2018 at 21:25:01 UTC, Jonathan M Davis wrote:
> > every feature that you can't use in betterC is considered a
> > loss, and efforts are being made to make more of them work.
> > There's always going to be a limit to that, and some D features
> > just plain require druntime (just like some of C++'s features
> > require a runtime), but it was never the point of betterC to
> > strip out a bunch of D features. That's just the natural
>
> It is what it is and if what it is is the best tool to fix a
> problem I would not hesitate to use it to that end.
>
> But you make it sound like betterC _should only_ work if actual D
> code is called otherwise stick with good old C. From the POV of a
> C programmer most of what betterC offers is a net gain and
> nothing is a loss because what are they losing by upgrading from
> C? And in general not paying for something you don't use or need
> is considered a gain, no?

I'm saying that -betterC is a subset of D that does not include D's runtime,
and it includes as many of D's features as it currently can without using
the runtime. You can choose to use it and never use normal D code, but the
reason that it was created in the first place was so that it would be
easier to port C code to D. Without -betterC, you tend to be forced to port
the entire program at once, whereas with it, you can port it in pieces and
then only switch to normal D once everything has been ported over. But there
are some folks who elect to just write code targetting -betterC and who
never intend for it to work as normal D code.

> > consequence of the goal of being callable from C code without
> > needing to worry about druntime.
> > All of those features that betterC can't use can be avoided in
> > normal D code if you don't want them for whatever reason.
> > nothrow is actually one of the few cases where you have to
> > explicitly do something in order to avoid that list of features
> > that you have there. In the other cases, you just don't use the
> > feature, and the only cost you're paying is the startup and
> > shutdown time for druntime and the few resources that it uses.
>
> Please tell me. How would I disable just the Error mechanism, for
> example ?
> As far as I can tell it's not sufficient that I don't use nothrow
> in my code because if it was used in phobos or druntime or some
> other D code I'd have to deal with it.

As with pretty much every other feature, if you don't want any Errors, you
just don't use anything that uses it. The same goes with the GC and other
features that you might choose to avoid. In some cases, that can be quite
limiting, but it is possible to avoid it. It's simply that just like with
any feature, avoiding it means losing out on features.

The primary difference with nothrow over most other features is that the
compiler inserts code by default for Exceptions if nothrow isn't there. So,
using nothrow is required to turn that off, whereas for most other features,
they only get used if you choose to use them (or use something that uses
them). But it has nothing to do with Errors either way. The only way to
avoid those is to never use a feature that could throw them (which can be
done but would be so limiting that it's probably a waste of time).

> But I know the answer to that. It's not possible because it was
> never considered because why would anyone want to do that and
> have the program just crash.
>
> Let's say I don't want to deal with OutOfMemoryError. That means
> essentially I'm losing the GC. Which sucks big time as it is
> _the_ selling point for me to use D over C.
>
> Let's say I didn't agree with RangeError for assoc. Arrays. I
> imagine it allocates dynamically and hence has a dependency on
> the GC so I have to consider the OutOfMemoryError headache even
> if I would agree to RangeError. Solution again don't use it and
> implement my own.
>
> Really, I don't see the difference between not using a feature
> and not having a feature available; result's the same - I need a
> solution/replacement.

If having the program crash due to an error condition being considered fatal
is unacceptable to you, then D will be unacceptable to you - including with
-betterC, since in that case, the Errors get turned into failed C assertions
that aren't compiled out. So, you won't get the stack unwinding, but your
program will be purposefully killed either way, because it encountered an
error condition that is considered fatal. You're free to disagree with that
approach, and you're free to disagree with which error conditions are
considered fatal, but it's part of using D. So, you'll either have to learn
to live with that or use a different language.

- Jonathan M Davis