Draft JEP: Keyword Management for the Java Language

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