Andrei Alexandrescu Wrote: > Hello, > > > I think the floating-point operators: > > a !<>= b > a !<> b > a <> b > a <>= b > a !> b > a !>= b > a !< b > a !<= b > > are useless. A simple peephole optimization in the compiler can > automatically rewrite NaN test followed by regular operations into the > operations above, for example: > > isNaN(a) || isNan(b) || a >= b > > is the same as > > a !< b > > This is in keeping with what the compiler does when seeing code like: > > a = x / y; > b = x % y; > > There's a peephole optimization that groups the / and the % together > into an assembler operation that does both. If this is the way to go, we > better be congruent and use explicit isNaN tests (that are then > optimized) instead of defining eight extra operators. > > > Andrei
I like the concept of NaN-aware operators, but IMHO, the most common operators are prone to misuse. If D moves for the peephole optimizations, I'd request a function called ordered(a,b) in addition to isNaN(a). Non-nullable and non-nanable types would be handy...
