> De: "Brian Goetz" <[email protected]> > À: "Remi Forax" <[email protected]> > Cc: "amber-spec-experts" <[email protected]> > Envoyé: Dimanche 13 Septembre 2020 20:34:54 > Objet: Re: Updated patterns-in-switch doc
>>> I don’t quite get the leap from “no constant patterns” to changing the >>> syntax of >>> deconstruction patterns, but in any case, we definitely don’t want this >>> (and in >>> fact, for the same reasons cited in the section on constant patterns, and >>> others.) >> if case Point(x, y) can not mean instanceof Point p where p.x == x && p.y == >> y, >> then case Point(x, y) can have the same meaning has a lambda (x, y), >> introducing two fresh variables x and y. > If you're making the claim that "It would not be disastrously inconsistent for > it to work that way", I agree. But I think it would still be quite foolish of > us to go that way anyway. The benefit is tiny (a few fewer characters typed) > at > a very considerable cost -- reduced readability, and potential ambiguities. The main issue i see with using var is that when you have nested patterns, "var" starts to becomes noise because you start to have several of them, so it makes the nesting less obvious. For me, var is good the first times to see how pattern matching works, it's very similar how as a beginner you are prefixing everything with "this" but after some times, it falls into the noise category, that why i'm not proposing to not allow "var" but to allow to not use "var". Again, this is very similar to the things we were discussing during the conception of lambdas, should we try to protect them with a lot of syntax to say, this is the new thing or should we try to make the syntax simpler with the risk of people not understanding it. Rémi
