Looks neat. Some comments:
* I note that you introduced patterns to describe the new syntactic
options; while that's a completely fine choice, I wonder if it could
lead to confusion - I always thought of JEP 325 as a set of standalone
switch improvements, which don't need the P-word to be just
Let's see if we can make some progress on the elephant in the room --
ancillary fields. Several have expressed the concern that without the
ability to declare some additional instance state, the feature will be
too limited.
The argument in favor of additional fields is the obvious one; more
As one of the voices demanding we allow ancillary fields, I can confirm
that I had only these derived-state use cases in mind. I don't see anything
else as legitimate. That is, I think that the semantic invariants you're
trying to preserve for records are worth fighting for, and additional
*non-der
Along the lines of the previous mail, people have and will ask "why
can't I redefine equals/hashCode". And the answer has two layers:
- The constraints on equals/hashCode are stronger for records, and
users might inadvertently violate them. (They can be specified in the
overrides of equals/
