> De: "Brian Goetz" <brian.go...@oracle.com> > À: "Remi Forax" <fo...@univ-mlv.fr> > Cc: "amber-spec-experts" <amber-spec-experts@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.go...@oracle.com | >>> <brian.go...@oracle.com> ] >>> À: "Swaranga Sarma" [ mailto:sarma.swara...@gmail.com | >>> <sarma.swara...@gmail.com> ] Cc: "amber-dev" [ >>> mailto:amber-...@openjdk.java.net | <amber-...@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.swara...@gmail.com | >>>> <sarma.swara...@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
