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.
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
----- Mail original -----
De: "Brian Goetz" <brian.go...@oracle.com>
À: "Swaranga Sarma" <sarma.swara...@gmail.com>
Cc: "amber-dev" <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 <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
