D is dead

[Walter Bright]

On 8/23/2018 3:12 PM, David Nadlinger wrote:
> On Thursday, 23 August 2018 at 21:31:41 UTC, Walter Bright wrote:
>> My personal opinion is that constructors that throw are an execrable 
>> programming practice, and I've wanted to ban them. (Andrei, while sympathetic 
>> to the idea, felt that too many people relied on it.) I won't allow throwing 
>> constructors in dmd or any software I have authority over.
> 
> Throwing constructors are fundamental for making RAII work in a composable fashion.

I understand my opinions on this diverge from the conventional wisdom.


> If constructors are not allowed to throw and you want to avoid manually creating 
> a "uninitialized" state – which is error-prone and defeats much of the point of 
> an RAII strategy –, all dependencies need to be injected externally, that is, 
> constructed independently and then passed into the constructor. Sometimes, 
> inversion of control is of course the right call – cf. the hype around DI –, but 
> sometimes you'd rather cleanly abstract the implementation details away.
> 
> Banning them from the language only pushes the complexity of handling 
> semi-constructed objects into ad-hoc user code solutions, which I'd argue is 
> worse in terms of usability and potential for bugs.
> 
> I suppose you view this as advantageous because you place more weight on the 
> language not having to explicitly deal with this scenario in the text of the 
> specification?

It's easy to specify. That's not an issue at all. It's also easy to implement - 
where my PR for it failed, was it broke existing code that should never have 
compiled anyway (for example, a nothrow constructor would then call a throwing 
destructor, or an @safe constructor now would call an unsafe destructor). 
Dealing with this likely means a compiler switch so an upgrade path is easier.

Let's deal first with the easy case - throwing destructors. The problem is that 
unwinding the stack to deal with the exception means calling destructors. You 
then have the infamous "double fault exception", and C++ deals with it by 
terminating the program, which is hardly useful.

D deals with it via "chained exceptions", which is terrifyingly difficult to 
understand. If you believe it is understandable, just try to understand the 
various devious test cases in the test suite. I regard D's chained exceptions as 
an utter failure.

Back to throwing constructors.

1) They are expensive, adding considerable hidden bloat in the form of finally 
blocks, one for each constructing field. These unwinding frames defeat 
optimization. The concept of "zero-cost exception handling" is a bad joke. (Even 
Chandler Carruth stated that the LLVM basically gives up trying to optimize in 
the presence of exception handlers.) Herb Sutter has a recent paper out 
proposing an alternative, completely different, error handling scheme for C++ 
because of this issue.

2) The presence of constructors that throw makes code hard to reason about. (I 
concede that maybe that's just me.) I like looking at code and knowing the 
construction is guaranteed to succeed. Somehow, I've been able to use C++ for 
decades without needing throwing constructors. Let's take the canonical example, 
a mutex:

   {
     Mutex a; // acquires a mutex, throws if it fails
     ... locked code ...
   } // mutex is released

My suggestion:

   {
     Mutex a; // creates a mutex
     a.acquire(); // does the obvious thing
     ... locked code ...
   } // mutex is released

It's still RAII, as the destructor checks to see if the Mutex is required, and 
if so, releases it.

You might argue "my code cannot handle that extra check in the destructor." Fair 
point, but stack that against the cost of the EH bloat in the constructor, and 
(for me) the inherently unintuitive nature of a constructor that tries to do far 
too much.

3) Much of the utility of throwing constructors in C++ comes from "what if the 
constructor fails to allocate memory". In D, out of memory errors are fatal, no 
recovery is necessary. That pushes any requirement for throwing constructors to 
the fringes in the first place.