Nothrow, pure in druntime

[Don]

Walter Bright wrote:
> dsimcha wrote:
>> 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.
> 
> This will do it:
> 
> nothrow:
> ... rest of module ...
> 
> 
>> Isn't errno defined in some implementations to be thread-local?
> 
> Yes, but thread local doesn't mean pure.
> 
>> 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.
> 
> Don has already reimplemented most of them in D, this was done to:
> 
> 1. ensure a minimum level of performance and accuracy; some C ones are 
> crappily done
> 
> 2. properly support all the D floating point types and overloading rules
> 
> 3. support NAN and INFINITY correctly

tango.math doesn't use the C library at all, except when inline asm is 
unavailable. Of they differ from the C functions, in that none of them 
set errno!
One really annoying issue still remains, though -- the floating point 
flags in the CPU. They are entirely deterministic, but are they 
considered to be part of the return value of the function? Or would we 
allow them to be ignored?
A compiler could check the exception flags before allowing memoisation. 
But one could also do the same thing for 'errno'.

Likewise, floating point rounding modes. Essentially, the floating point 
   status register is a hidden global variable, read from# and written 
to during every floating point operation.

# - only the rounding mode and truncation affect the return value. We 
could deal with it by regarding that as a whole-program setting. But 
(depending on the CPU), the old exception flags generally get ORed with 
the new exception flags.

Also, you can set the flags to allow any floating point function to 
throw a hardware exception. It's difficult for any function using 
floating point to claim to be nothrow under ANY circumstances; but 
that's a horrible limitation.