handling T.min the right way

[Pragma]

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.
> 
> The right way is to have T.min always return the minimum value (duh) and 
> define a separate property T.min_positive.
> 
> The question is, would a lot of code be hurt by such a change?
> 
> 
> Andrei

No issue here.  In fact, I've never used "double.min" for example - I'm suprised to hear that it's positive.

As much as I'd like to see D embrace camelCase for multi-word things, "foreach_reverse" has pretty much decided that one 
for us - T.min_positive seems like a good addition to the language as any.  I gather this means that we'll also see a 
t.max_negative to go along with it?
-- 
- EricAnderton at yahoo