operators !=

[Samuel Gaist]

On 25 août 2014, at 11:06, Samuel Gaist <samuel.gaist at edeltech.ch> wrote:

> Answer from Aaron
> 
> Begin forwarded message:
> 
>> From: "Aaron J. Seigo" <aseigo at kde.org>
>> Subject: Re: operators !=
>> Date: 25 août 2014 10:12:11 UTC+02:00
>> To: Samuel Gaist <samuel.gaist at edeltech.ch>
>> 
>> On Monday, August 25, 2014 09.17:03 you wrote:
>>> So if we expend this thing a bit, it might look like:
>>> var x != 3;
>>> which would be the same as:
>>> var x = !0x03;
>>> which would translate to
>>> var x = 0xFB;
>> 
>> That's an interesting interpretation, and one of the reasons I'm uncomfortable 
>> with defining '!=' as the literal antonym of '=' in all manners.
>> 
>> But no, != is a boolean operator only allowing for "assignment on not equals". 
>> It leads to visually "strange" things like:
>> 
>> var x != 3;
>> 
>> which would be functionally equivalent to:
>> 
>> var x = 3;
>> 
>> This follows from:
>> 
>> var x = 3;
>> (x, var y) = [4, 2]; 
>> 
>> Element 0 does not equal 3, so y is not assigned and we get an error. There 
>> are more complex use cases where this becomes actually useful in a non-trivial 
>> manner.
>> 
>> Now, if != is the literal antonym of =, then we get things like this:
>> 
>> var x = 3;
>> (x, var y) != [4, 2]; 
>> 
>> Element 0 does not equal 3, so y gets assigned. That can be useful and is 
>> nicely consistent with how '=' is used in pattern-matching assignment. 
>> Unfortunately it also leads to trivial cases that will not behave as most 
>> people would expect on first glance:
>> 
>> var x != 3;
>> 
>> Variable x is not yet bound to a value, so != always succeeds and assigns 3.
>> 
>> It's the trivial case that looks odd, while the non-trivial cases (where 
>> pattern-matching assignment actually becomes sensible) look sensible.
>> 
>> Honestly, I'm torn between:
>> 
>> 	a) != is an antonym of =
>> 	b) != means "not equals", has nothing to do with assignment, breaking 
>> symmetry with =
>> -- 
>> Aaron J. Seigo
> 

Since it should be a boolean operator, I'd rather go for b. 
It will probably avoid lots of questioning and "strange logic" looking code