On Jul 23, 2020, at 11:38 AM, Remi Forax <[email protected]> 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
