Almost everything in druntime's core.sys.posix is currently ..not..
nothrow. This causes (me) to workaround by wrapping it with try/catch
statements which is completely unnecessary, it would be easier to just
copy those files in the project folder and change them unless they're
updated in the git head by some kind of a hero ;)
Wouldn't it be easier if extern(c) implied nothrow? you betcha!

And you aren't submitting a pull request with those changes because...
On 4/9/14, 8:47 PM, Etienne wrote:

Almost everything in druntime's core.sys.posix is currently ..not.. nothrow.
This causes (me) to
workaround by wrapping it with try/catch statements which is completely
unnecessary, it would be
easier to just copy those files in the project folder and change them unless
they're updated in the
git head by some kind of a hero ;)
Wouldn't it be easier if extern(c) implied nothrow? you betcha!

And you aren't submitting a pull request with those changes because...

Well, I was hoping for someone to catch on with the extern(C) = nothrow idea.
Maybe this reallyy
belongs in DMD!

It shouldn't, because it's not 100% true, even for libc related functions.
Consider qsort and it's
function pointer parameter. There's other examples of the same. Just because
most are no through
doesn't imply they all are. Leave the realm of libc and it's even less true.
Consider all the C
wrappers for c++ libraries. It's perfectly legal for any of those to throw.
So, not gonna happen. Please do consider spending a little time to open pull
requests for the ones
that it's safe to be specified as nothrow. Someone has to and the more people
investing little bits
of their time the better. Waiting for someone else to do it for you could be a
very long wait.

And you aren't submitting a pull request with those changes because...

Well, I was hoping for someone to catch on with the extern(C) = nothrow idea.
Maybe this reallyy
belongs in DMD!

It shouldn't, because it's not 100% true, even for libc related functions.
Consider qsort and it's
function pointer parameter. There's other examples of the same. Just because
most are no through
doesn't imply they all are.

Well, the intention was good. If I may add: Don't pass a D
function that throws to C/C++ code on Linux/GNU x86_64.
DMD's stack unwinder relies on how the D compiler writes
stack frames. In particular it expects frame pointers, which
aren't used by default on that arch. As a result druntime will
terminate your application.

Leave the realm of libc and it's even less true. Consider all the C
wrappers for c++ libraries. It's perfectly legal for any of those to throw.

Isn't that paradox? Why is it legal to throw C++ exceptions
into a language that can't possibly look at them? Does that
mean every language which interfaces with C handles
C++ exceptions in some way? E.g. JNI, Python, ...?
I mean, to be legal it has to be defined to do something
specific, other than killing your program on the spot.
--
Marco

Isn't that paradox? Why is it legal to throw C++ exceptions
into a language that can't possibly look at them? Does that
mean every language which interfaces with C handles
C++ exceptions in some way? E.g. JNI, Python, ...?

It's obviously blown out of proportion. We should put a grill in D so
that we can cook hamburgers if they're thrown through C. ^^

So, not gonna happen. Please do consider spending a little time to open
pull requests for the ones that it's safe to be specified as nothrow.
Someone has to and the more people investing little bits of their time
the better. Waiting for someone else to do it for you could be a very
long wait.