Pattern Matching for switch (Second Preview)

[Remi Forax]

> 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>