www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Equality operator chaining?

reply "bearophile" <bearophileHUGS lycos.com> writes:
Few days ago I have suggested a small language enhancement:
http://d.puremagic.com/issues/show_bug.cgi?id=11410


In Python this code is allowed:


 x = 3
 y = 4
 z = 5
 x < y < z






True



It is compilable in C too:


int main() {
     int x = 3;
     int y = 4;
     int z = 5;
     int b = x < y < z;
     return 0;
}


But GCC tells us with a warning that code doesn't work as 
expected by a Python programmer:

test.c:5:15: warning: comparisons like 'X<=Y<=Z' do not have 
their mathematical meaning [-Wparentheses]
      int b = x < y < z;


So D disallows that code, giving:

test.d(5): Error: semicolon expected, not '<'
test.d(5): Error: found '<' instead of statement

- - - - - - - - - - - - - -

GCC accepts this code:


int main() {
     int x = 4;
     int y = 4;
     int z = 4;
     int b = x == y == z;
     return 0;
}


With a warning:

test.c:5:15: warning: suggest parentheses around comparison in 
operand of '=='
[-Wparentheses]
      int b = x == y == z;


While DMD refuses that code:

test.d(5): Error: semicolon expected, not '=='
test.d(5): Error: found '==' instead of statement


In D I find several situations where a chained equality is handy:

if (n == foo(n) == bar(n) && ...

It avoids code like this, that needs an auxiliary variable:

aux = foo(n);
if (n == aux && aux == bar(n) && ...


Is this idea going to cause troubles with operator overloading or 
something else? Do you like it? Is it important enough?

Bye,
bearophile
Nov 10 2013
next sibling parent reply =?UTF-8?B?IsOYaXZpbmQi?= <oivind.loe gmail.com> writes:
     int b = x == y == z;


Although GCC accepts the code, I don't think it does what you 
think here. It will basically z will be compared with '1', which 
is the value of (4 == 4), and b will become 0, or false.
Nov 10 2013
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Øivind:


 Although GCC accepts the code, I don't think it does what you 
 think here. It will basically z will be compared with '1', 
 which is the value of (4 == 4), and b will become 0, or false.


OK, so it's like in the chained < comparisons.

So I presume D disallows the chained equality for the same 
reasons it disallows the chained < comparisons.

Bye,
bearophile
Nov 10 2013
parent reply "Meta" <jared771 gmail.com> writes:
On Sunday, 10 November 2013 at 19:32:58 UTC, bearophile wrote:

 Øivind:


 Although GCC accepts the code, I don't think it does what you 
 think here. It will basically z will be compared with '1', 
 which is the value of (4 == 4), and b will become 0, or false.


 OK, so it's like in the chained < comparisons.

 So I presume D disallows the chained equality for the same 
 reasons it disallows the chained < comparisons.

 Bye,
 bearophile


I was re-reading TDPL recently, and Andrei explicitly mentions 
this. The reason D disables this instead of allowing it is 
because it was deemed a bad idea to allow the code to compile 
with different semantics than the equivalent C code.
Nov 10 2013
parent "bearophile" <bearophileHUGS lycos.com> writes:
Meta:


 I was re-reading TDPL recently, and Andrei explicitly mentions 
 this. The reason D disables this instead of allowing it is 
 because it was deemed a bad idea to allow the code to compile 
 with different semantics than the equivalent C code.


I understand, I close down the ER...

Bye,
bearophile
Nov 10 2013
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 11/10/2013 11:08 AM, "Øivind" wrote:

     int b = x == y == z;


 Although GCC accepts the code, I don't think it does what you think here. It
 will basically z will be compared with '1', which is the value of (4 == 4), and
 b will become 0, or false.


Which is exactly why D rejects this code.

And, if D accepted the code, but gave it Python semantics, then C code that did 
work would silently break.

So no, D's behavior should not be changed.

(This is an old topic, we've gone over it before.)
Nov 10 2013
prev sibling parent Shammah Chancellor <anonymous coward.com> writes:
On 2013-11-10 18:45:14 +0000, bearophile said:

 It avoids code like this, that needs an auxiliary variable:
 
 aux = foo(n);
 if (n == aux && aux == bar(n) && ...
 
 
 Is this idea going to cause troubles with operator overloading or 
 something else? Do you like it? Is it important enough?
 
 Bye,
 bearophile


if( n == (foo(n) == bar(n)))  is legal.
Nov 10 2013