Pattern matching on multiple objects

[Swaranga Sarma]

I was recently writing a simple state machine where the machine state has
simple deterministic rules for the state transitions given the current
state and the input. I felt both the state and the input types lent
themselves well to sealed classes and records but while implementing the
logic I had to resort to if-else statements. At that point, I felt if I
were able to switch and pattern-match on both the input types together as a
tuple, my logic would have been much clearer while also concise.

Simplified sample code that I wish to be able to write (although the point
is not the exact syntax):
sealed interface State {}
record Start() implements State {}
record First() implements State {}
record Second() implements State {}
record End() implements State {}

sealed interface Move {}
record Jump(int steps) implements Move {
Jump {
if (steps < 0 || steps > 2)
throw new IllegalArgumentException();
}
}
record None() implements Move {}

State transition(State initial, Move move) {
return switch(initial, move) {
case (Start, Jump(1)) -> First;
case (Start, Jump(2)) | (First, Jump(1)) -> Second;
case (First, Jump(2)) | (Second, Jump(_)) -> End;
case (End, _) -> End;
case (None, _) -> initial;
}
}

I did not see in the amber docs about being able to use multiple patterns
in a switch expression in any of the future plans. It does not even have to
be a switch really but something to allow this type of expressivity. This
feels very much in line with the Data Oriented programming article
published a while ago.

Even if something like this were possible, I am guessing a default clause
would be needed in the switch because the compiler cannot infer that
Jump(1) and Jump(2) are the only valid jumps. Being able to help the
compiler  by expressing such constraints at the language level would be
even more amazing but that is a whole other topic.

Would something like this be possible one day?

Regards
Swaranga
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20230423/f1d73b9f/attachment.htm>