It can quickly get out of hand, so _ is a pretty well-known and widely used approach here in ML-like languages, and its usage causes no harm at all.
Personally, I think the instanceof syntax for Records is terrible and you're showing off exactly why. It breaks encapsulation entirely. What we need to do is fix records so they will have more OOP related principles. instanceof is a patch and switch should be an anti-pattern. If records allowed inheritance we could just add polymorphic APIs to them and then write more elegant code without the instanceof's.
Sure, but I’m sure it was not an automatic copy, but a well thought-out design by the very competent design team.
> It breaks encapsulation entirely
Records are almost by definition open. They are only the sum[1] of their constituents. They are part of a more data-oriented approach.
Of course the “old” OOP concerns may apply, and there is an escape hatch — one can make a class from a record, and with the coming destructors it won’t need any recompilation, every existing pattern match can work, yet its inner workings can be encapsulated. But this is not the primary purpose for them — they are just plain old data.
EDIT: though now that I thought a bit about it, hopefully with `withers` we get an alternative syntax for pattern matching on records, like `ColoredPoint { point: 3DPoint { x } }`. That way pattern matching won’t be tied to the order of the fields. Surely records don’t change often, but still.
[1] if we are being pedantic, they are the product of their constituents, they are named product types.
instanceof ColoredPointer(x, color)
is even shorter and it's really not hard to come up with a variable name. In this case some tools might mark x as unused but that's just nonsense.
The catch example is interesting but how often do you completely ignore the exception and should you ever do that?
Is that behavior the language should encourage?
I feel that this is a solution to a very minor inconvenience that is pretty redundant.