Pattern Matching for switch (Second Preview)
Remi Forax
forax at univ-mlv.fr
Fri Oct 1 13:12:48 UTC 2021
> From: "Gavin Bierman" <gavin.bierman at oracle.com>
> To: "Brian Goetz" <brian.goetz at oracle.com>
> Cc: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> 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:brian.goetz at oracle.com |
>> brian.goetz at oracle.com ] > 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20211001/442238dc/attachment.htm>
More information about the amber-spec-experts
mailing list