What is the point of nothrow?

[wjoe]

On Monday, 18 June 2018 at 20:23:48 UTC, Jonathan M Davis wrote:
> 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.

That's not how it came across.
It came across like the _entire_ purpose of it is to call D stuff 
without the need to deal with the druntime and nothing else.

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

So basically everything safe for what is betterC.

> 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).
>
> If having the program crash due to an error condition being 
> considered fatal is unacceptable to you, then D will be

I never made that claim. Unacceptable to me is the implemented 
mechanism.

> 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

yes, it will be terminated via sigabrt. Which is the way it's 
supposed to be.
Not to continue running to a function that prints possibly 
invalid stuff, iff a console like device is attached, and abort 
in a central, completely unrelated, part of the druntime.
If no console is attached, you'll end up with nothing.

Seriously, the entire mechanism is contradicting itself. How can 
it declare program state invalid and unfit to continue at the 
point the Error was detected and thrown but do it regardless ?

> 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

One could also argue that Exceptions are an integral part of 
using D and there is really never a situation where you need to 
turn it off just like there is never a situation where you would 
catch an Error. Deal with it.

If a programming language doesn't so much as to help the 
developer to be more productive, e.g. by making it easier to 
squash bugs but, by definition i.e. invalid program state, make 
it impossible to troubleshoot them, then this language is at 
least a bad decision from an economic point of view. Which makes 
it a toy language.

I know that much of what can be done actually works in practice 
but that's not the point. As soon as program is in invalid state 
it must not continue but immediately abort - and if it continues 
regardless nothing at all can be relied upon, including what the 
druntime spits out before aborting because the druntime is, at 
least by definition, in invalid state, too.
And all of this is completely unrelated to my personal opinion.