struct opCmp?

[BCS]

Hello Nick,

> "BCS" <none at anon.com> wrote in message
> news:a6268ff5d188cba2e03b08e7a0 at news.digitalmars.com...
> 
>> Hello Nick,
>> 
>>> Yea, I agree. But at the very least, I was thinking that we could
>>> use a warning when opCmp is defined and opEquals isn't. Can anyone
>>> think of a reasonable case where it would actually make sense to
>>> override opCmp, but not opEquals? (that is, without bastardizing
>>> them like in a "C++ streams" kind of way)
>>> 
>> what about where you want to disallow == like with floating point
>> like cases? I know it doesn't work this way, but if you define opCmp
>> and not opEquals, I wouldn't mind ==/!= being defined to
>> unimplemented.
>> 
> Interesting idea. Although can't </>/<=/>= also have accuracy problems
> when the values are close?
> 

Yes but at least they sometimes work. with == you might as well have the 
optimizer replace it with false.