Pattern matching will work fine with an additional explicit nil() pattern. I agree that in this particular case it's not quite as succinct as in more functional languages, but virtually all cases in ordinary business applications are not like that, and the additional code, if any, is O(1).
Of course, Java could add rules for the special case of zero-argument records, making them more enum-like, but I really think the value in doing that is negative. Other than being able to directly translate ML examples, it would add complexity that isn't worth it.
In fact, in this particular case I'd do it like so:
record List<T>(T car, List<? extends T> cdr) {
public List { if (car == null) throw new IllegalArgumentException("null element"); }
}
Which would give you:
switch(list) {
case List<String>(var car, var cdr) -> ...
case null -> ...
}
It might not be exactly what people who like Scala might prefer, but it is very much a good representation of ADTs for those who prefer Java.
I don't think so.
> I was not able to define a classical list with cons and nil in Java.
If you want to restrict Nil to a single instance, don't make it a record class:
You can statically import if you mind them not being "top level": And then write, say: Not as succinct as ML, but workable.Although, in this particular case,
would suffice.