What to do about #1661 (operator nodes) ? Sensible solution would be to make AdditiveExpression be parsed completely left-recursively, but then, it looks weird that all other binary expressions are not left-recursive…

The problem also arises for operators &, |, ^, which may be boolean non-shortcut expressions or numeric bitwise expressions

Arguments for left recursiveness:

• Preserve all intermediary type resolution results, because of numeric promotion -> the whole point of [java] RFC: new layer of abstraction atop PrimaryExpressions #497
• AST is JLS-like, easier to document (we don’t have to explain “sometimes it’s left-recursive and sometimes not”)
  ((1 + 4) + returnString()) = “14” “5”
  ((1 + 4) + 4) == (1 + 4 + 4)
• Easier mapping of type resolution algorithms from the JLS
• Stronger contract for binary expressions: all can present the same interface:

getLhs() : ASTExpression
getRhs() : ASTExpression
getOperator() : BinaryOp

• Classpath independent

Arguments against:

• Not super intuitive
• Breaks away from previous AST structure, needs to be relearned
• Needs more tooling for some use cases:

Eg how to catch a string concat statement like a = … + a + …; (use case taken from #1932's AvoidConcatInLoop)

• In Java we can imagine the following method for binary expressions which yields all operands that are added with the same operator: operandStream(): NodeStream<ASTExpression>
  Eg for <a + b + c * d>, operandStream returns Stream.of(<a>, <b>, <c * d>). So you can do eg:

 additiveExpr.operandStream()
                   .filter(ASTVariableAccess.class)
                   .any(ref -> ref.getName().equals(“a”))

• However in XPath it’s less trivial.. We’d have to provide access to the node stream with a function:
  • Old way, with flat additive expr:

AdditiveExpression[@Operator=”+”]/VariableReference[@Image = “a”]

• New way:

AdditiveExpression[@Operator=”+”]
     [pmd-java:operandsOf(.)/self::VariableReference[@Image = “a”]]