Most basic nothrow, pure, @safe functions?

Steven Schveighoffer schveiguy at yahoo.com
Tue Mar 18 16:20:15 PDT 2014


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


More information about the Digitalmars-d mailing list