handling T.min the right way

[Don Clugston]

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

It probably wouldn't break a huge amount of D code, but I don't think 
there would be many cases where T.min for a floating point type would be 
useful. More significant is the problems involved in converting from C 
or Fortran code to D.

On a more profound level...
I'm not aware of many cases where it's possible to treat integer and 
floating-points generically. People often try, but usually the code is 
incorrect for the floating point types, since the semantics are 
completely different. (For example, I don't know why x++ is legal for 
floating point types; I think it's just a newbie trap; you have no 
guarantee that x++ is different to x).

What type of generic numeric code did you have in mind? What are the 
benefits which would come by such a change?