Draft JEP: Keyword Management for the Java Language (original) (raw)

Remi Forax forax at univ-mlv.fr
Wed May 1 20:21:32 UTC 2019

----- Mail original -----

De: "Alex Buckley" <alex.buckley at oracle.com> À: "jdk-dev" <jdk-dev at openjdk.java.net> Envoyé: Mercredi 1 Mai 2019 21:22:10 Objet: Re: Draft JEP: Keyword Management for the Java Language

Remi, thanks for your comments.

On 5/1/2019 5:07 AM, Remi Forax wrote: - for the constraints on hyphenated keywords, using int-typed expressions is perhaps a little too clever because the compiler has to provide meaningful error message for the user (and IDEs automatic completion of not yet fully form expressions), by example, if there is an hyphenated keyword new-fun, for the snippet return A::new-fun, the expression is not valid but there are two interpretations A::new - fun or A:: new-fun. I think it's better to use a grammar approach (which keywords can be at left side or right side of an expression). Also the current rule doesn't work well if in the future we want to introduce operator overloading. I had some trouble understanding "using int-typed expressions is perhaps a little too clever", because they're just examples to make a point, while "a little too clever" is the kind of comment usually targeted at a fundamental design decision. I think what you mean is "a little too limiting".

Thanks for reading my mind and not what i've written

To spell it all out:

1. Type-correct expressions that perform subtraction are part of the "overlap" with hyphenated keywords; and 2. Type-incorrect statements that complete abruptly are part of the overlap too (throw-quickly is syntactically valid today -- it will lex and parse if quickly is a numeric variable -- but it is also semantically invalid (type error), so we COULD reclassify it as a hyphenated keyword, but we have ALREADY decided not to, per how throw is mentioned in set A); and 3. [Remi's observation] Type-incorrect expressions that perform subtraction are part of the overlap too (A::new-fun is syntactically valid today, but semantically invalid, so we COULD reclassify it as a hyphenated keyword, but we should be consistent with #2 and forbid new-* hyphenated keywords like we do for throw-*). (You also raise the point that if the - operator could be overloaded, then it might be semantically valid for the left operand to be a method reference expression involving ::new, and that would clash super-badly with new-* hyphenated keywords.)

I think 'this' are also missing from {A}, Foo.this is a valid expression (while semantically invalid).

For 'null', 'true' and 'false', there are also valid expression but invalid semantically, so following the same logic they should be in {A} and {B}.

in that case non-null is not a valid hyphenated keyword but it's a valid hyphenated keyword if contextual (as modifier for a field or a method).

tl;dr I will add new to set A, and avoid so much focus there on int-typed expressions.

- the example total-switch in section "hyphenated keywords" is invalid given the constraints you give. Oops! Removed. Alex

regards, Rémi

More information about the jdk-dev mailing list