Nothrow, pure in druntime

[dsimcha]

== Quote from Walter Bright (newshound1 at digitalmars.com)'s article
> dsimcha wrote:
> > I've started looking at the best way to annotate all the pure/nothrow
> > functions in druntime.  A lot of druntime functionality calls functions from
> > the C standard library or the Windows/POSIX API.  I figure the best way to get
> > started is to deal w/ these first, and then worry about the higher level stuff
> > that's built on to of it.  These functions are obviously nothrow, since C
> > doesn't even support exceptions.  First of all, is there a decent automated
> > way to fix all of the declarations for these functions so that they're nothrow?
> I did think of making all functions that are extern(C) automatically
> nothrow, but was concerned that it would result in a lot of bugs and
> broken code from ones that did throw.

I assume, when referring to the ones that do throw, you mean functions written in
C++ or D, but declared w/ C linkage.  If so, you could make this a per-module
setting that defaults to not assuming nothrow.  For example, let's say you made
this pragma(Linkage, nothrow).  Then, if this statement is seen at the top of a
module, everything declared with extern(Linkage) in that module is assumed to be
nothrow.  For standard C, Windows and POSIX API functions and for any library
written in pure C, I believe (correct me if I'm wrong) this would be a safe
assumption.  At any rate, it would make nothrow a heck of a lot more usable.


> Functions that modify errno cannot be pure. What needs to be done is go
> through the definition of each. For example, strlen, strcmp, etc. can be
> marked as pure. printf and strtok cannot.
> The math functions can be a problem since earlier incarnations often
> messed with global state, but with the advent of thread safe C runtime
> libraries, this shouldn't be an issue anymore.

Isn't errno defined in some implementations to be thread-local?  If so, I guess we
still have a problem.  Then again, in the long run it probably makes sense to
reimplement a lot of the math stuff that still uses the C std lib in pure D anyhow
so that things like CTFE work on it, but in the sort run I'm sure that's not
anyone's top priority.