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!

On 2014-04-10 00:01, Brad Roberts wrote:
> 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!

On 4/9/14, 9:49 PM, Etienne Cimon wrote:
> On 2014-04-10 00:01, Brad Roberts wrote:
>> 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.

Am Wed, 09 Apr 2014 22:19:30 -0700
schrieb Brad Roberts <braddr@puremagic.com>:

> On 4/9/14, 9:49 PM, Etienne Cimon wrote:
> > On 2014-04-10 00:01, Brad Roberts wrote:
> >> 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

On 2014-04-10 2:51 AM, Marco Leise wrote:
> 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. ^^

On 2014-04-10 1:19 AM, Brad Roberts wrote:
> 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.

I shall proceed promptly.