Next up for patterns: type patterns in switch

[John Rose]

On Jul 23, 2020, at 11:38 AM, Remi Forax <forax at univ-mlv.fr> wrote:
> 
> In next releases? Add constant Pattern and static Pattern. Ban instance pattern because you don't want to match something that depends on a mutable states (my worst experience with Scala).

Do you mean mutable states in some sort of pattern token (which is
not AFAIK on the table) or mutable states in the object-being-tested
or mutable states in a pattern parameter (e.g., an object being compared
to the object-being-tested)?  In the latter two cases, the mutability bug
is that you test an object and it passes a test on Tuesday but not today,
either because the object changed, or the *other* object hanged.

I see there are horrible bugs there, but for Java that ship is already sailed.
Object::equals/hashCode can depend on mutable state; equals can depend
on mutable state in the second operand.  Programmers just have to deal
with it, or choose to use immutables (inlines! records!).

Patterns amount to a more generous slice of the functionalities
which Object::equals/hashCode also serve.  If we try to “tighten up”
some aspect of patterns to avoid mutability bugs, we’ll just force
users to drop down to Object::equals, for no strong reason IMO.

Banning instance patterns (while allowing static patterns) just puts
in a cardboard wall that makes it slightly harder to code some bugs
but will greatly annoy legitimate designers and users.

(Or do I misunderstand your point?)

— John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20200723/8bb15115/attachment.htm>