Hi,

I have a design question, or maybe it is a bug ? In D, == and != have the same precedence than comparisons operators. This isn't the case in C/C++ . Is it a design decision, made on purpose ? Is it a bug ?

DMD implementation and http://dlang.org/expression.html both agree on that.

I personally think it is a bug. This is a change in the behavior of C/C++ with no legitimate reason. Or at least with no legitimate reason I can come up with.

Probably a good way to force parentesys usage and avoid subtle bugs...

On Monday, 2 April 2012 at 10:01:20 UTC, deadalnix wrote:
> Hi,
>
> I have a design question, or maybe it is a bug ? In D, == and != have the same precedence than comparisons operators. This isn't the case in C/C++ . Is it a design decision, made on purpose ? Is it a bug ?
>
> DMD implementation and http://dlang.org/expression.html both agree on that.
>
> I personally think it is a bug. This is a change in the behavior of C/C++ with no legitimate reason. Or at least with no legitimate reason I can come up with.

On Mon, 02 Apr 2012 12:03:14 +0200, deadalnix <deadalnix@gmail.com> wrote:

> Hi,
>
> I have a design question, or maybe it is a bug ? In D, == and != have the same precedence than comparisons operators. This isn't the case in C/C++ . Is it a design decision, made on purpose ? Is it a bug ?
>
> DMD implementation and http://dlang.org/expression.html both agree on that.
>
> I personally think it is a bug. This is a change in the behavior of C/C++ with no legitimate reason. Or at least with no legitimate reason I can come up with.

It's there to force proper parenthezation:

1 <= 3 == 2 > 3 != 3 < 1
vs
((1 <= 3) == (2 > 3)) != (3 < 1)
vs
(1 <= (3 == 2)) > ((3 != 3) < 1)

On 02/04/2012 11:32, Simen Kjaeraas wrote:
> On Mon, 02 Apr 2012 12:03:14 +0200, deadalnix <deadalnix@gmail.com> wrote:
>> I have a design question, or maybe it is a bug ? In D, == and != have the same
>> precedence than comparisons operators. This isn't the case in C/C++ . Is it a design
>> decision, made on purpose ? Is it a bug ?
<snip>
> It's there to force proper parenthezation:
<snip>

That combined with associativity rules.

In C(++),
    a < b == c <= d
means
    (a < b) == (c <= d)

However, if one simply made all the comparison operators equal precedence, then the meaning of this would change to
    ((a < b) == c) <= d

However, what has actually been done is to make these operators non-associative as well, in order to render it an illegal expression.  This was done to prevent subtle typos or confusion with other languages/notations where chaining of comparison operators denotes a conjunction of the comparisons.

Another way to look at it is that the different comparison operators have no precedence relative to each other (though each still needs to be non-associative).  Indeed, another change that has taken place is to make the comparison operators have no precedence relative to the bitwise boolean operators, simply because the C precedence rules here were confusing.
http://d.puremagic.com/issues/show_bug.cgi?id=4077

Stewart.

Le 02/04/2012 13:10, Stewart Gordon a écrit :
> On 02/04/2012 11:32, Simen Kjaeraas wrote:
>> On Mon, 02 Apr 2012 12:03:14 +0200, deadalnix <deadalnix@gmail.com>
>> wrote:
>>> I have a design question, or maybe it is a bug ? In D, == and != have
>>> the same
>>> precedence than comparisons operators. This isn't the case in C/C++ .
>>> Is it a design
>>> decision, made on purpose ? Is it a bug ?
> <snip>
>> It's there to force proper parenthezation:
> <snip>
>
> That combined with associativity rules.
>
> In C(++),
> a < b == c <= d
> means
> (a < b) == (c <= d)
>
> However, if one simply made all the comparison operators equal
> precedence, then the meaning of this would change to
> ((a < b) == c) <= d
>
> However, what has actually been done is to make these operators
> non-associative as well, in order to render it an illegal expression.
> This was done to prevent subtle typos or confusion with other
> languages/notations where chaining of comparison operators denotes a
> conjunction of the comparisons.
>
> Another way to look at it is that the different comparison operators
> have no precedence relative to each other (though each still needs to be
> non-associative). Indeed, another change that has taken place is to make
> the comparison operators have no precedence relative to the bitwise
> boolean operators, simply because the C precedence rules here were
> confusing.
> http://d.puremagic.com/issues/show_bug.cgi?id=4077
>
> Stewart.

So basically, the precedence doesn't matter because any situation where it matter is illegal anyway ?

Parentesys are needed only where there's ambiguity with precedence.

a > b > c is ambiguous (we need parentesys)
a == b > c  is amibiguous (we need parentesys because == and > have the same precedence)

a == b && c is not ambiguous ( && and == haven't the same precedence so we don't need parentesys)

On Monday, 2 April 2012 at 12:02:33 UTC, deadalnix wrote:
> Le 02/04/2012 13:10, Stewart Gordon a écrit :
> So basically, the precedence doesn't matter because any situation where it matter is illegal anyway ?

On 4/2/2012 5:04 AM, deadalnix wrote:
> So basically, the precedence doesn't matter because any situation where it
> matter is illegal anyway ?

That's correct and neatly sums up the situation.

Le 02/04/2012 15:49, Walter Bright a écrit :
> On 4/2/2012 5:04 AM, deadalnix wrote:
>> So basically, the precedence doesn't matter because any situation
>> where it
>> matter is illegal anyway ?
>
> That's correct and neatly sums up the situation.

Merci :D