handling T.min the right way

[Frits van Bommel]

Andrei Alexandrescu (See Website For Email) wrote:
> A while ago, C++ did the mistake of defining 
> std::numeric_limits<T>::min() with a different semantics for 
> floating-point types than for integral types. That hurt generic numeric 
> code a lot.
> 
> D has taken over the same mistake: T.min means the smallest value of the 
> type, except for floating-point types, where it means the smallest 
> positive value.

???
This statement really surprised me. But it does seems to be what DMD does.

The relevant line of the spec 
(http://www.digitalmars.com/d/property.html [section on floats]):
---
.min 	smallest representable normalized value that's not 0
---
Does "normalized" imply non-negative?

I guess I could have expected this behavior if I'd paid better attention 
to this line though, since it's '0' that is explicitly excluded instead 
of negative infinity. (Also, it uses "smallest" instead of something 
like "lowest")

> The right way is to have T.min always return the minimum value (duh) and 
> define a separate property T.min_positive.

Obviously.
Since the minimum positive number would be a denormalized value 
(right?), perhaps a T.min_normalized as well?
(or if "normalized" doesn't imply non-negative, min_normalized_positive, 
though that's getting a bit long...)

> The question is, would a lot of code be hurt by such a change?

I didn't even know this wasn't already how it worked...