handling T.min the right way

[Andrei Alexandrescu (See Website For Email)]

Don Clugston wrote:
> 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.

I'm not even discussing the utility of min_positive. All I'm saying is 
that if you say "min", you should return "min", particularly when others 
do exactly that.

> 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?

Trivially simple: the min and max functions. For min, the code picks the 
type with the smallest .min. For max, the code picks the type with the 
largest .max.


Andrei