> On Sep 7, 2018, at 2:41 PM, Brian Goetz <brian.go...@oracle.com> wrote: > > I've updated the documents regarding pattern matching, and uploaded them here: > > http://cr.openjdk.java.net/~briangoetz/amber/pattern-match.html
"if the data structure is a tree represents a design in a CAD application” => "if the data structure is a tree that represents a design in a CAD application” (add “that”) "case AddNode(Node left, Node right)) -> …” => "case AddNode(Node left, Node right) -> …” (delete extraneous right paren) At end of section “Composing patterns”, show an actual example of multiply nested patterns, such as "AddNode(Node x, IntNode(int n))”. "whether the manifest type adds or distracts from readability and maintainability” => "whether the manifest type adds to or distracts from readability and maintainability” (add “to”) "it is also reasonably to have” => "it is also reasonable to have” It’s worth pointing out that one possible spelling of “__let” is to use no token at all. Then certain degenerate cases are the same as when using a local variable declaration with initializer. > http://cr.openjdk.java.net/~briangoetz/amber/pattern-semantics.html > > The first document is an update of a previous document (old version available > here: http://cr.openjdk.java.net/~briangoetz/amber/pattern-match_1.html), and > outlines the general arc of the feature and general motivation. > > The second captures the discussions we've had regarding the messy details of > typing, scoping, nullability, shadowing, etc. I think we've made a lot of > progress on these. > > We would not implement this all at once; we'd proceed incrementally, probably > starting with type patterns in `instanceof`, and then proceeding to `switch` > or to deconstruction patterns. > > Please review and comment. >
