nothrow by default

[Ola Fosheim Grøstad]

On Sunday, 5 January 2020 at 10:32:23 UTC, Johannes Pfau wrote:
> I totally agree to that (memory overhead, TypeInfo, support 
> code). In addition, this overhead means that exceptions are 
> unlikely to be supported in embedded systems, which will lead 
> to a language ecosystem split (this effectively happened to 
> C++).

Not only the overhead, but in real-time interrupts have to be 
100% sure that no code triggers a system call or ends up waiting 
for a lock to be released. Also in applications (e.g. audio 
drivers).

Seems to me that static analysis could be used for this, the same 
way @nogc works.  I think D should look at something more 
comprehensive regarding managing resources instead of these  
tweaks that have very little positive impact.


> Rationale: There are two common ways to handle errors: 
> Backtrace/ exception based and error code based. Both have 
> drawbacks (exceptions: performance, memory / implementation 
> overhead, not supported in embedded systems) (error codes: not 
> "bubbling up" the call stack automatically, no way to force 
> user to check, so might accidentially ignore errors).

Yes, but back-tracing with error codes can be slow.

RAII can be slow.

You can have exceptions in real time systems (setjmp), basically 
just reload saved register values that sets the stack pointer and 
program counter to a consistent state.

So an exception (set jump) can be  much faster than back-tracing 
if you have no RAII on the call stack and all allocations are 
done either on the stack and all other resources are bound to an 
Arena-allocator/manager at the landing pad.

What makes C++-style exceptions slow is the unwind library's 
cross-language design and the surrounding RAII philosophy... 
Exceptions, as a concept, are not necessarily slow. If you can 
just set the stack pointer and jump to the landing pad then you 
have something much faster than returning/unwinding down the call 
stack for deep call-trees.

But since D should be able to call C++ code that won't work, and 
nothrow by default will not help with C++. So to get anywhere you 
first have to figure out how to interact with C++ code. If you 
call C++ code then you cannot assume that it won't throw, unless 
it is marked as "noexcept" and even if it is noexcept it still 
can have landing pads. So you cannot bypass the unwinding 
library... Am I right?

In terms of supporting generic programming it is better to have 
"possibly throws" everywhere.