Using <> for opCmp

[Lionello Lunesu]

"Stewart Gordon" <smjg_1998 at yahoo.com> wrote in message 
news:ekcecj$iig$1 at digitaldaemon.com...
> Lionello Lunesu wrote:
> <snip>
>> The thing is, <> already exists! It's doing too much at the moment: it 
>> converts the int return value from opCmp to a boolean.
>
> Exactly.  And that's indeed what I'd expect it to do.  Why do you feel 
> that it's "too much"?

The original opCmp return value is lost, so currently <> is exactly the same 
as != (except using opCmp instead of opEquals, I'd hope). Converting the 
integer return value to a boolean is an extra operation, with added 
instructions. If this 'conversion to bool' was to be dropped, if (a<>b) 
would still behave the same way, with less instructions, and the added 
benifit of access to opCmp's value.

At the moment, if you want to distinguish between the three cases, a<b, 
a==b, a>b, you will have to do two comparisons (resulting in either one call 
to opCmp and one to opEquals, or two calls to opCmp). To prevent these extra 
comparisons, you have to call opCmp explicitely, but then you'll have to 
know the type of the variables (for built-ins you need different code than 
for classes), not mentioning the fact that you reference the function opCmp 
(which I think should be hidden as much as possible).

Now, if <> were to return the opCmp return value as an integer, you can do 
int cmp = a<>b; and have the three cases (<, ==, >) right there, without 
having to call opCmp, or worrying about the types. And it'll be faster code, 
too.

I'm really rather surprised by the resistance. I'm not suggesting a new 
operator, merely changing an existing one slightly, improving its 
performance, whilst keeping it backward compatible. It should be a dead 
giveaway. Not getting people convinced shows how bad I am at making my point 
:S

L.