Hi Gavin,
Thanks for the reply – yes, agree with you in that precedence doesn’t figure
out here – my bad I went into a wrong path in the grammar.
That said, with further analysis, the code in question:
case String a && o != null ? true : false -> 1;//ecj flags syntax
error here
is still an error because there seems to be no way for the reduction into
conditionalAndExpression as mentioned below.
Ie:
case String a && o != null ? true : false -> // Reject
Add a parenthesis and then we get a path – side note/
case String a && (o != null ? true : false) -> // Accept
because,
without parenthesis, ie the code:
case String a && o != null ? true : false ->
follows the path of:
AssignmentExpression -> ConditionalExpression
Expression ::= AssignmentExpression
ConstantExpression -> Expression
And this cannot be reduced to a ConditionalAndExpression and consequently not
further to a GuardedPattern
while the one with parenthesis, can be reduced to GuardedPattern eventually
case String a && (o != null ? true : false) ->
AssignmentExpression -> ConditionalExpression
Expression ::= AssignmentExpression
PrimaryNoNewArray ::= ‘(‘ Expression_NotName ‘)’
ie and so on..
Primary -> PrimaryNoNewArray
PostfixExpression -> Primary
…
InclusiveOrExpression -> ExclusiveOrExpression
ConditionalAndExpression -> InclusiveOrExpression
…
With the combination of “String a &&” eventually leading to
GuardedPattern ::= PrimaryPattern AND_AND ConditionalAndExpression
Regards,
Manoj
From: Gavin Bierman <gavin.bier...@oracle.com>
Date: Friday, 11 March 2022 at 1:51 AM
To: Manoj Palat <manoj.pa...@in.ibm.com>
Cc: "amber-spec-experts@openjdk.java.net" <amber-spec-experts@openjdk.java.net>
Subject: [EXTERNAL] Re: [18][guarded pattern] conditional-and query - spec
clarification
Hi Manoj, It’s a slightly moot point, given that we are likely to drop guarded
patterns in the next preview but I think there has been some confusion here...
On 7 Mar 2022, at 07:08, Manoj Palat <manoj.pa...@in.ibm.com> wrote:
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd
Hi Manoj,
It’s a slightly moot point, given that we are likely to drop guarded patterns
in the next preview but I think there has been some confusion here...
On 7 Mar 2022, at 07:08, Manoj Palat
<manoj.pa...@in.ibm.com<mailto:manoj.pa...@in.ibm.com>> wrote:
Hi,
Given,
public void bar(Object o) {
int i = switch(o) {
case String a && o != null ? true : false -> 1;//ecj flags syntax
error here
default -> 1;
};
}
ECJ(eclipse compiler for Java) flags a syntax error on the guarded pattern.
However, javac accepts.
Ecj translates this into:
case ((String a) && (o != null)) ? true : false
and flags an error instead of
case ((String a) && ((o != null) ? true : false))
The idea of guarded patterns is that we give a secondary role to `&&` to serve
as an operator for patterns.
After the `case` we parse a pattern. One of the form of a pattern is a guarded
pattern which is:
GuardedPattern:
PrimaryPattern && ConditionalAndExpression
Given the grammar as per
http://cr.openjdk.java.net/~gbierman/jep420/jep420-20211208/specs/patterns-switch-jls.html<http://cr.openjdk.java.net/~gbierman/jep420/jep420-20211208/specs/patterns-switch-jls.html>
I think javac is parsing this correctly.
I don’t know quite what ecj is doing here because the translation you give
above seems to suggest that it was accepting an expression after the `case`
which is not correct. Moreover, the inner expression (String a) && (o != null)
is not an expression but a (guarded) pattern.
And I think the ecj is correct in flagging the error due to:
From
https://docs.oracle.com/javase/tutorial/java/nutsandbolts/operators.html<https://docs.oracle.com/javase/tutorial/java/nutsandbolts/operators.html>
we see that Conditional-And Operator “&&” has higher operator precedence
than the Conditional Operator “?:” . From
https://docs.oracle.com/javase/specs/jls/se17/html/jls-15.html#jls-15.23<https://docs.oracle.com/javase/specs/jls/se17/html/jls-15.html#jls-15.23>,
we see that “The conditional-and operator is syntactically left-associative
(it groups left-to-right).”
Also, I don't see any mention of the precedence changes in spec 420 [latest at
https://cr.openjdk.java.net/~gbierman/jep420/latest<https://cr.openjdk.java.net/~gbierman/jep420/latest>]
I don’t see the connection with precedence - we certainly didn’t make any
changes.
Am I understanding your issue correctly?
Thanks,
Gavin
