Operator precedence of && and ||

There is an issue concerning logical expressions (i.e. expressions that are evaluated to true or false, a.k.a Boolean expressions) in X++. The essence of this issue is that the X++ language is not aligned with other languages in its precedence of the logical and (&&) and or (||) operators. In X++ these two operators have the same precedence, whereas in other languages && is higher priority than ||.


The issue here is that programmers might unexpectedly create bugs for themselves when writing complex Boolean expression involving these two operators. For instance:


A || B && C


(where A, B and C are Boolean subexpressions) will be evaluated as (A||B) && C in X++, but as A || (B && C) in every other languages that I know of.


This unfortunate operator priority choice has been there since the first version of the X++ language. The workaround, of course, is simple (use parenthesis to group together the sub-expressions), but there is a potential for bugs that may be subtle. We have had no reports from the user base about this problem. It is unclear to me at this time if this is explicitly called out in any documentation that we have, but I doubt it.


The morale is this: Always group together your complex Boolean expressions with parenthesis to aid both you and the compiler.


We have been very reluctant to align the precedence of the logical operators to other languages, because we fear breaking existing code in the user code base. I would love to hear the opinions of the people out there in the trenches. Let us know: Do we let sleeping dogs lie, or go ahead and fix it?

Comments (7)

  1. JanKjeldsen says:

    Personally, I have never relied on the X++ operator precedence of ||/&& (I use parenthesis as described).

    This precedence is a remnant of XAL (and where XAL got it, I don’t know).

    My advice: get rid of it.

    Maybe add a search tool to search for combined use of &&/|| without parenthesis.

  2. casperkamal says:

    I generally use a parenthesis…. coz i know it is the safest way….

    Probably we should get this out and make it fall in line with other languages

  3. SysDictCoder says:

    I always use parentheses for complex expressions, no matter which language I’m working in.  Whenever I’m involved in training/mentoring others I advise them to do so as well.  It makes intentions clear and increases readability (combined with some line breaks:)).

    That being said I tend to disagree with those who commented before me.  I would not change it at this point because it would probably introduce bugs in existing code.  I’m sure some code works "by accident" because of the current operator precedence.  Using the same precedence as other languages would be good but I don’t perceive this as a major issue.  In my experience people learn to deal with it quickly and don’t complain much once they realize it’s different.  Perhaps it’s not worth the trouble.

  4. CJU says:

    Oh please, you won’t change this will you? I am dead sure that a change of this ‘aberration’ will break thousand lines of code. And though I know that most other languages works differently I got used to this behavior during the last six year and I think many other people too. You could have done this in 2000 latest but now? Please not!

  5. steeveg@hotmail.com says:

    I am on the "don’t fix it" side.  Even thought it would be cleaner if it was like other languages, I think it doesn’t worth the trouble of taking a chance of creating new bugs just to conform to the norm.  Like others said, when an expression get a bit complex, just use parenthesis and you’ll be safe.

  6. rmcintyre says:

    I’m new to X++ and am fortunate to have stumbled here before falling into this trap.  Here’s what I’d like to see done (in order of difficulty):

    1.  A 1-page beginner reference on x++ language paradigms (such as this) that are non-standard vs. other common languages.

    2.  This particular idiosyncrasy eliminated along with a code conversion script… or at least a compiler warning if there’s there a logical operation without parenthesis.

    3.  X++ (along with its weak text editor) deprecated entirely and converge to c#/Visual Studio.

  7. gverny says:

    At the end of the day I’m on "fix it" side.

    And actually I don’t believe that there are solutions that are conciously depend on such behavior.

    But since we actually can not predict the impact of the change (we can on SYS / GLS / DIS side but there are partner/customer solutions!) my proposed steps are

    1. Adding BP warning on logical operator mixing && and || without parenthesis.

    2. Following release (+1) – switch to BP error.

    3. Following release (+2) – stick to standard && / || precedence.

    PS: [ emotion ] arithmetical bug (3/3 + 3/3) = 3 was corrected relatively fast, while bug in logical operation (true || false && false) = false persists for years…

Skip to main content