nothrow in druntime win32 C bindings

[Brad Roberts]

On Thu, 27 Dec 2012, Walter Bright wrote:

> On 12/27/2012 1:52 AM, deadalnix wrote:
> > On Thursday, 27 December 2012 at 09:29:08 UTC, Walter Bright wrote:
> > > D does use Windows SEH for win32, but not for win64. But still, you gotta
> > > ask
> > > yourself, what do expect Windows to do with a D exception?
> > 
> > I think it has several advantages to use the same ABI :
> >   - Exception cal bubble from D to C++ then back to D to be handled. C++
> > will
> > run RAII code properly, even if it can't do anything useful with the D
> > exception. This is common when using function pointer or virtual methods.
> >   - The same thing goes the other way around : C++ Exception can go throw D
> > code, unwinding stack cleanly. Even if D program cannot do anything really
> > ith
> > the C++ exception, it can at least fail safely and with a stack trace.
> > 
> > In many cases, exception are more about exit cleanly than actually catch
> > them
> > and recover. For such a case, common ABI is useful.
> 
> There is some merit to your argument, and that was the original idea behind
> building D exceptions out of Win32 SEH. I did the same for the Digital Mars
> C++ compiler.
> 
> But in practice, and I include a decade with DMC++, I've just never seen a
> useful application of it.

It doesn't matter if you can see the utility in it or not.  What matters 
is some combination of user expectations and general usability, both of 
which are fairly subjective.  Additionally, for most of that decade, 
mixing languages was fairly rare.  These days it's becoming increasingly 
common.  Presenting c++ libraries with c wrappers is much more common now.  
Using call backs and registration hooks for plugins and other 
extensibility mechanisms is WAY more common now than it was 10 years ago.  
In short, the landscape has and continues to change, so past history is a 
poor measuring stick for future code bases.

IMHO, having the unwinders NOT be common and uniform in behavior is a 
major usage problem.  It might not be important enough to hit the top of 
the todo list right now, but at some point it's going to be.  Either way, 
not being interoperable is a bug in my mind (and I include all the 
platform here, not just windows) and will need to be addressed.  It's 
roughly in the same category as supporting shared libraries.  They're not 
important at small scale, but at large scale they start to become 
critical.  If I can't rely on proper unwinding, there's going to be 
problems.

I'm not familiar with the windows side, but on the posix side, the c++ 
world developed a fairly sane, multi-language, unwinding system.  There's 
little reason NOT to use it, other than that it takes a little time to 
understand and hook into it, and going off on your own path is potentially 
simpler.

My 2 cents,
Brad