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

[forax at univ-mlv.fr]

> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> Envoyé: Dimanche 26 Avril 2020 23:15:03
> Objet: Re: Why are the curly braces required for a minimal Record declaration?

> No, this is not why we did it.

> This was the first form of expression that can embed statements. This raises the
> ugly question of nonlocal control flow. We felt it would simply be too
> complicated to be able to return/continue out of the middle of evaluating an
> expression -- this would be a significantly new form of control flow for
> expressions. Instead, evaluating an expression must either yield a value, or
> throw, as it has always been with expressions.
Thanks, 
I've forgotten that you have to trash/cleanup the stack before being able to jump or return. 
By forcing, users to use the switch statement, we avoid that case. 

regards, 
Rémi 

> On 4/26/2020 5:08 PM, Remi Forax wrote:

>> 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).

>> regards,
>> Rémi

>> [1] [
>> https://github.com/forax/valuetype-lworld/blob/master/fr.umlv.jsonapi/src/main/java/fr/umlv/jsonapi/JsonReader.java#L206
>> |
>> 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" [ mailto:brian.goetz at oracle.com | <brian.goetz at oracle.com> ]
>>> À: "Swaranga Sarma" [ mailto:sarma.swaranga at gmail.com |
>>> <sarma.swaranga at gmail.com> ] Cc: "amber-dev" [
>>> mailto:amber-dev at openjdk.java.net | <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 [ mailto:sarma.swaranga at gmail.com |
>>>> <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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20200427/0143062d/attachment.htm>