What is the point of nothrow?

[wjoe]

On Saturday, 16 June 2018 at 21:25:01 UTC, Jonathan M Davis wrote:
> On Saturday, June 16, 2018 18:45:53 wjoe via 
> Digitalmars-d-learn wrote:
>> What you said earlier:
>>
>> On Monday, 11 June 2018 at 00:47:27 UTC, Jonathan M Davis 
>> wrote:
>> > [...]
>> >
>> > 2. If the compiler knows that a function can't throw an 
>> > Exception, then it doesn't have to insert any of the 
>> > Exception handling mechanism stuff [...] So, the fact that a 
>> > function is nothrow gives you a performance benefit, [...]
>> >
>> > - Jonathan M Davis
>>
>> made me believe that performance is one of the major reasons 
>> to use it. No?
>>
>>  From the betterC page https://dlang.org/spec/betterc.html 
>> section
>> 40.2:
>> ---
>> Not Available
>>
>> D features not available with BetterC:
>>
>>      Garbage Collection
>>      TypeInfo and ModuleInfo
>>      Classes
>>      Built-in threading (e.g. core.thread)
>>      Dynamic arrays (though slices of static arrays work) and
>> associative arrays
>>      Exceptions
>>      switch with strings
>>      final switch
>>      synchronized and core.sync
>>      Static module constructors or destructors
>>      Struct destructors
>>      unittest (testing can be done without the -betterC flag)
>> ---
>> Apart from a few convenience features lost this list reads 
>> like a shopping list for performance gain over full fledged D, 
>> in the spirit of nothrow omitting exception handling 
>> mechanism, to me. You gain from no garbage collection 
>> overhead, no vtable overhead, no RTTI overhead, no exception 
>> overhead, etc, etc, ...
>>
>> Back in the late 90ies I used to write the lion's share of 
>> code in Pascal and implement mission critical algorithms in 
>> asm. Worked back then why wouldn't it work today, except that 
>> I wouldn't use asm anymore but something like C or betterC.
>>
>> Thus, people who need this kind of performance boost can 
>> benefit
>> 2 fold from using betterC.
>> 1. They get to keep most of D's awesomeness, including compile
>> time features, scope statements, RAII, lack of a pre processor,
>> memory safety protections and complete meta programming, are 
>> just
>> _some_ of the highlights. And on the other hand
>> 2. they gain by getting rid of a lot the 'performance hogs' 
>> like
>> GC, exceptions and more, right?
>> And, with no exceptions altogether they do not need to worry
>> about it at all.
>>
>> I'm sold!
>
> The _entire_ point of betterC is to be able to call D code from 
> C code without having to deal with druntime (you can call D 
> code from C code even without betterC, but then you have to 
> worry about initializing and shutting down druntime). Basically

BetterC sounds like a C language with tons of features from.. 
well actually...it sounds like a C language that fixes C's 
shortcomings.
To get that point across it should maybe be called C2D Easy 
Interop Language.

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

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

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.

> So, while you might choose to use betterC over concerns about 
> the performance of D features that betterC doesn't allow, that 
> was never the point of betterC.
>
> - Jonathan M Davis

Looks like one can only choose the headache to deal with.

Now, from the point you make about betterC, it seems like a 
better idea to abandon ship now and return to C instead of having 
to deal with similar headaches with betterC in the future.