In a recent (well, recently pulled anyway) pull request that Monarch Dodra brought up, we debated what should be considered nothrow in the depths of druntime.

I think we all agree that there are some things that the compiler simply cannot prove are nothrow, but to be able to write useful nothrow code, we have to paste nothrow on there anyway.

It got me thinking, we really should determine exactly at what level nothrow, pure, and @safe should be "overridden" inside druntime, and apply those low-level attributes. Then everything above them can be checked by the compiler.

In the case of the recent pull, https://github.com/D-Programming-Language/druntime/pull/553, assumeSafeAppend was the culprit. The function uses the heap's metadata to determine the exact block that a slice points at, and adjusts the "used" field stored as part of that appendable block. However, it calls some monitor enter and monitor exit functions that are not marked nothrow, due to synchronizing on a lock.

We all agreed that nothing that assumeSafeAppend did should really throw, and so the pull just used c linkage to "add" nothrow to an otherwise unmarked function. But that solution isn't very good. At some point, the function *could* throw (I hope not), and then the forced nothrow will create silent bugs.

It would be better if we could mark the lowest level functions possible nothrow, and figure out which ones we had to "force". Same goes for pure and @safe.

This is not exactly a proposal, but an idea that we should consider at some point to do this analysis. I don't think it will be very difficult, but probably tedious.

-Steve

Steven Schveighoffer:

> But that solution isn't very good. At some point, the function *could* throw (I hope not), and then the forced nothrow will create silent bugs.

Walter has recently proposed optimizations for nothrow functions (like this: https://d.puremagic.com/issues/show_bug.cgi?id=12384 ). If nothrow is circumvented and the function throws, the program goes into undefined behavour at best. So I agree that those annotations should start from the ground up.

Bye,
bearophile

On 3/18/2014 4:20 PM, Steven Schveighoffer wrote:
> In a recent (well, recently pulled anyway) pull request that Monarch Dodra
> brought up, we debated what should be considered nothrow in the depths of druntime.

There's a lot of low hanging nothrow fruit in druntime that doesn't need analysis, it just needs to get done:

https://d.puremagic.com/issues/show_bug.cgi?id=12389

On Tue, 18 Mar 2014 19:48:45 -0400, Walter Bright <newshound2@digitalmars.com> wrote:

> On 3/18/2014 4:20 PM, Steven Schveighoffer wrote:
>> In a recent (well, recently pulled anyway) pull request that Monarch Dodra
>> brought up, we debated what should be considered nothrow in the depths of druntime.
>
> There's a lot of low hanging nothrow fruit in druntime that doesn't need analysis, it just needs to get done:
>
> https://d.puremagic.com/issues/show_bug.cgi?id=12389

Can we mark _d_monitorenter and _d_monitorexit nothrow and have the compiler see that when using synchronized? This was the hurdle we couldn't overcome in the referenced pull request.

Should those be marked nothrow? What about pure and @safe?

-Steve

On 3/18/2014 4:56 PM, Steven Schveighoffer wrote:
> Can we mark _d_monitorenter and _d_monitorexit nothrow and have the compiler see
> that when using synchronized? This was the hurdle we couldn't overcome in the
> referenced pull request.
>
> Should those be marked nothrow? What about pure and @safe?

Good question. I don't have an answer at the moment.

On 3/19/2014 8:20 AM, Steven Schveighoffer wrote:

> We all agreed that nothing that assumeSafeAppend did should really
> throw, and so the pull just used c linkage to "add" nothrow to an
> otherwise unmarked function.

Does this mean that extern(C) functions are automatically considered nothrow? That is not my current understanding.

On 3/18/2014 6:56 PM, Mike Parker wrote:
> Does this mean that extern(C) functions are automatically considered nothrow?

No.

On 19/03/14 00:20, Steven Schveighoffer wrote:
> I think we all agree that there are some things that the compiler simply cannot
> prove are nothrow, but to be able to write useful nothrow code, we have to paste
> nothrow on there anyway.

Just to clarify my understanding here: exactly how much compiler checking _is_ done of nothrow?  Is it simply to confirm that whatever is called by the function contains no "throw" statements (hopefully all the way down ...), or is there more ... ?

What I'm wondering is whether just as we have @safe and @trusted for the situations where the compiler can verify and where the programmer has verified, is there a case for complementing nothrow with another attribute ("wontthrow"?) that's a programmer assurance rather than a compiler-checked guarantee?

I imagine if that was worthwhile someone would already have done it, but I'm curious.

On Tue, 18 Mar 2014 21:56:54 -0400, Mike Parker <aldacron@gmail.com> wrote:

> On 3/19/2014 8:20 AM, Steven Schveighoffer wrote:
>
>> We all agreed that nothing that assumeSafeAppend did should really
>> throw, and so the pull just used c linkage to "add" nothrow to an
>> otherwise unmarked function.
>
> Does this mean that extern(C) functions are automatically considered nothrow? That is not my current understanding.

No, but extern C functions are not mangled. Therefore, the declaration can be nothrow, but the implementation not have that attribute, and linking still works. It's a way to work around the compiler checks.

-Steve

On 2014-03-19 08:59, Joseph Rushton Wakeling wrote:
> On 19/03/14 00:20, Steven Schveighoffer wrote:
>> I think we all agree that there are some things that the compiler
>> simply cannot
>> prove are nothrow, but to be able to write useful nothrow code, we
>> have to paste
>> nothrow on there anyway.
>
> Just to clarify my understanding here: exactly how much compiler
> checking _is_ done of nothrow?  Is it simply to confirm that whatever is
> called by the function contains no "throw" statements (hopefully all the
> way down ...), or is there more ... ?

It checks that any exceptions thrown in the function body are caught in a try/catch, and that any functions not marked nothrow are similarly handled in a try/catch. I believe that is all.

For templated functions, the compiler does the same to figure out if the instantiation is nothrow. Thus a function can call a templated function that's not marked nothrow if its body can be compiled as such.

--
  Simen