> From: "Brian Goetz" <brian.go...@oracle.com> > To: "Remi Forax" <fo...@univ-mlv.fr> > Cc: "amber-spec-experts" <amber-spec-experts@openjdk.java.net> > Sent: Wednesday, May 18, 2022 11:08:41 PM > Subject: Re: Pattern matching: next steps after JEP 405
>> Inference is also something we will need for pattern assignment >> Box<>(var s) = box; > Yes, it would work the same in all pattern contexts -- instanceof as well. > Every > pattern context has a match target whose static type is known. >>> - Array patterns. The semantics of array patterns are a pretty simple >>> extension >>> to that of record patterns; the rules for exhaustiveness, applicability, >>> nesting, etc, are a relatively light transformation of the corresponding >>> rules >>> for record patterns. The only new wrinkle is the ability to say "exactly N >>> elements" or "N or more elements". >> I wonder if we should not at least work a little on patterns on collections, >> just to be sure that the syntax and semantics of the patterns on collections >> and patterns on arrays are not too dissimilar. > This is a big new area; collection patterns would have to be co-designed with > collection literals, and both almost surely depend on some sort of type class > mechanism if we want to avoid the feature being lame. I don't think its > realistic to wait this long, nor am I aiming at doing anything that looks like > a generic array query mechanism. Arrays have a first element, a second > element, > etc; the nesting semantics are very straightforward, and the only real > question > that needs additional support seems to be "match exactly N" or "match first > N". We may want to extract sub-parts of the array / collections by example, and i would prefer to have the same semantics and a similar syntax. And i don't think we need type classes here because we can use the target class mechanism instead, like we have done with lambdas, instead of Type x -> x + 1 or whatever the exact syntax, we have (Type) x -> x + 1 We may want [1, 2, 3] to have a type, so it's maybe a little more complicated than just using the target typing but i don't think type classes are needed for collection litterals. For operator overloading on numeric value classes, that's another story. Rémi
