Why are the curly braces required for a minimal Record declaration?

Remi Forax forax at univ-mlv.fr
Sun Apr 26 21:08:56 UTC 2020

I'm glad you just send that message on amber-dev,
playing with the parsing of JSON [1], I stumble upon one of our decisions that i now regret,
switch expression doesn't allow return and continue while a switch statement do.

>From now, it look like a gratuitous "Tuesday rule". 

As a user if you want to use return and/or continue, you can transform your switch expression to a switch statement and it will work.
So by adding the fact that a switch expression doesn't support return/continue, we are making the code less readable because we are implicitly saying you should use a switch statement here, not a switch expression.

Trying to remember why we have decided to not support return/continue, i believe it was at the time we were using "break" as keyword instead of yield, and at that point the decision was making a lot more sense because we did want people to have trouble with break working differently from continue.

The good news is that currently the code doesn't compile, so if everybody agree, we can revert that decision and at the same time simplify the JLS (it will not simplify the compiler until the support of Java 14 is dropped).


[1] https://github.com/forax/valuetype-lworld/blob/master/fr.umlv.jsonapi/src/main/java/fr/umlv/jsonapi/JsonReader.java#L206

----- Mail original -----
> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "Swaranga Sarma" <sarma.swaranga at gmail.com>
> Cc: "amber-dev" <amber-dev at openjdk.java.net>
> Envoyé: Dimanche 26 Avril 2020 17:42:19
> Objet: Re: Why are the curly braces required for a minimal Record declaration?

> John and Remi correctly pointed out that some punctuation is necessary, and that
> having a special rule (like allowing a semicolon instead of a pair of braces)
> doesn’t really carry its weight, since it only saves one keystroke.  Here’s
> another reason.
> We actually did prototype it originally where you could drop the braces, and say
>     record Foo(int x);
> But it doesn’t take long before you start asking “can I omit the braces on an
> empty class or interface?  what about methods too?”  Which brings us to a
> general principle that is in play for a feature like this: minimizing the
> gratuitous differences between records and classes, because we don’t want to
> burden users with keeping a lot of silly rules in their head like “on tuesdays,
> you get two braces for the price of one.”
> This principle comes up over and over again; we saw one yesterday on this list
> (“can I please have non-nullable records”), and there are many more, ranging
> from the very reasonable-seeming “can I invoke a record constructor by
> parameter name rather than positionally” to the absurd “can we omit semicolons
> in records, it’s not incompatible” (yes, we actually got this one.)
> Every one of these differences adds friction:
> - Users have to remember that they can (do the new thing) in records, but not
> classes;
> - Users will complain “why can’t classes do this too”, and are quite likely to
> view the glass as being mostly empty rather than partially full;
> - It is harder or less compatible to migrate records to classes, because they
> will have features that can’t be represented in otherwise-equivalent classes.
> Like all “syntactic sugar”, there is the risk of a sugar high, and the resulting
> glycemic crash.  We tried to limit the sugar in records to that needed to
> achieve the semantic goal — nominal tuples.
>> On Apr 25, 2020, at 4:39 PM, Swaranga Sarma <sarma.swaranga at gmail.com> wrote:
>> Records is a new feature and does not carry the same baggage as classes do.
>> Looking at a minimal Record Point declaration:
>> record Point(int x, int y) {}
>> Every part of this declaration makes sense to me expect the curly braces
>> '{}'. Why is that required if I do no intend do override any part of the
>> record?
>> I am probably missing something; appreciate the insight.
> > -Swaranga

More information about the amber-spec-experts mailing list