Pattern Matching for switch (Second Preview)

Gavin Bierman gavin.bierman at oracle.com
Fri Oct 1 12:49:01 UTC 2021



On 30 Sep 2021, at 23:25, Brian Goetz <brian.goetz at oracle.com<mailto: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?

Gavin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20211001/ecb0ee7a/attachment.htm>


More information about the amber-spec-experts mailing list