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
- Most basic nothrow, pure, @safe functions? Steven Schveighoffer
-
