nothrow in druntime win32 C bindings

[Sean Kelly]

On Dec 27, 2012, at 5:46 PM, Brad Roberts <braddr at puremagic.com> wrote:

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

This. Is there some reason we really need a different unwinding mechanism?