> From: "Gavin Bierman" <[email protected]> > To: "Brian Goetz" <[email protected]> > Cc: "amber-spec-experts" <[email protected]> > Sent: Vendredi 1 Octobre 2021 14:49:01 > Subject: Re: Pattern Matching for switch (Second Preview)
>> On 30 Sep 2021, at 23:25, Brian Goetz < [ mailto:[email protected] | >> [email protected] ] > wrote: >> [ moving to a-s-e ] >> I get the concern that a type pattern is no longer "just a variable >> declaration"; that was a nice part of the "patterns aren't really so hard to >> understand" story. But I think the usability is likely to be not very good. >> Take this example: >> sealed interface Node<T> { } >> record AddNode<T>(Node<T> left, Node<T> right) extends Node<T> { } >> ... >> Node<int> ni = ... >> switch (ni) { >> case AddNode(Node left, Node right) -> ... >> There's no instantiation of Node possible here *other than* Node<int>. Which >> means we are forcing users to either redundantly type out the instantiation >> (which can get big), or use casts inside the body when they pull things out >> of >> left and right. (And patterns were supposed to make casts go away.) There's >> almost no case where someone wants a raw type here. > But surely they should write var here? yes, here is another example List<String> list = ... switch(list) { case ArrayList al -> ... > Gavin Rémi
