Project Amber is making progress on pattern matching in #JavaNext. Here are three recent developments that I'm very excited about and I think you will be as well.
(Caveats: these are ongoing discussions; none of this is final; speculation and strawman syntax ahead)
(Caveats: these are ongoing discussions; none of this is final; speculation and strawman syntax ahead)
1. "Array patterns" allow matching and destructuring arrays. The `if`-line does three things:
a) is `objects` a `String` array with length 2?
b) if so, cast it to `String[]` and extract the two elements
c) declare `a` and `b` and assign the two elements to them
a) is `objects` a `String` array with length 2?
b) if so, cast it to `String[]` and extract the two elements
c) declare `a` and `b` and assign the two elements to them
"Can I also bind the arrays as a whole?"
Likely. This is called an "as pattern".
"What if the array can have more elements?"
Allowing to express "at least two elements" is being considered - for example with three dots.
Likely. This is called an "as pattern".
"What if the array can have more elements?"
Allowing to express "at least two elements" is being considered - for example with three dots.
"Can I bind the array's remaining elements to a variable?"
No. Splitting an array into head and tail is expensive and invites recursive solutions that Java doesn't support well due to its lack of tail call elimination.
That's it for arrays.
No. Splitting an array into head and tail is expensive and invites recursive solutions that Java doesn't support well due to its lack of tail call elimination.
That's it for arrays.
2. If you squint, every declaration looks like a pattern match (1st image shows terminology, 2nd applies it to declaration). This invites the consideration to allow destructuring every declaration, be it in for-each loops (3rd), try-with-resources, method signatures, lambdas. 😍
3. As type patterns are finalized in #Java16, they work with generics as follows:
* if the tested type is raw, the variable is declared as the raw type
* if the variable should have a generic type, the test needs to spell out the generics
This is straightforward but not ideal.
* if the tested type is raw, the variable is declared as the raw type
* if the variable should have a generic type, the test needs to spell out the generics
This is straightforward but not ideal.
Imagine the example with more/nested generics, wildcards, and long class names. 😱
Maybe the pattern with the raw-looking type should have inferred generic types? The feature is finalized, but not shipped and could still be reverted to preview, so it can be changed later.
Maybe the pattern with the raw-looking type should have inferred generic types? The feature is finalized, but not shipped and could still be reverted to preview, so it can be changed later.
Another idea is to introduce the diamond operator in type patterns, to inform the compiler to infer generic types. This would be in line with how generics work elsewhere in the language 👍🏾, but would mean a lot more diamonds in code 👎🏾 .
How would you prefer to write a type pattern that infers generic types? And do you think the finalization of type patterns in #Java16 should be reverted for that?
This hiccup begs the question whether some features (in this case: all patterns) are better finalized or even released in one big chunk as opposed to the smaller featurettes that get released and finalized now.
What do you think? How to release/finalize big features?
What do you think? How to release/finalize big features?
• • •
Missing some Tweet in this thread? You can try to
force a refresh
