On Friday, 20 June 2014 at 11:07:48 UTC, Paolo Invernizzi wrote:
On Thursday, 19 June 2014 at 19:58:58 UTC, Walter Bright wrote:
<snip>
The callback function, being supplied by the D programmer, may
throw and may call the garbage collector. By requiring the
callback function to be also nothrow @nogc, this is an
unreasonable requirement besides breaking most existing D code
that uses qsort().
<d.learn>
I'm missing something, as I'm annotating all my C/API/etc
callback function with nothrow: when the callback throws, what
happens?
I was thinking that this will mess-up the stack once the unwind
will proceed...
What's the use-case for having such a callback 'throwable'?
Thanks!
</d.learn>
---
Paolo
This is actually a really good point. How can a callback in C
code expect to throw exceptions? Surely it should be nothrow
anyway, because it's just not going to work otherwise. Maybe we
should just strengthen the constraints for that, and make people
update their code which isn't likely to work anyway. You can make
any throwing function nothrow by catching Exceptions and throwing
Errors instead at least. Ideally you wouldn't even throw Errors
in C callbacks.
