That seems like a very contrived example. I don't work with Java regularly, but wouldn't that be better written as something like this?

    int total = max(orders.length, LIMIT);

But obviously for typical usage one should probably just use the stream API.

Is it related to anything more useful?

To pattern matching.

var _ = q.remove();

This is just stupid. We can write: q.remove();

We don't need to save the return value in Java. The only case where this makes sense is:

instanceof Point(_, int y)

But that makes sense because the original code is so bad. A better solution would be type inference like we have in lambdas:

instanceof Point(x, y)

If that method returns, many tools will complain that the returned value is ignored

In the case of delete() you would want to check the result. So the warning is good and using an underscore to ignore it would actually be a problem.

In the case of remove() we don't really need the result.

The real winner here is obviously the used example, `instanceof ColoredPointer(_, var color)`, here every other solution would be plain ugly. The other examples are just there to make the feature intuitive - for example I quite like the `catch (SomeException _)`, making it exact that this exception is deliberately not used up in the catch block.

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.

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.

  try (Timer ignored = Metrics.newTimer("getOrders")) {
    return db.getOrders();
  }

This JEP would allow stronger static analysis rules like "every declared parameter and variable MUST be used", and _ would serve as the canonical escape hatch for edge cases.

One datapoint: searching our codebase for variables named "ignored" produces >1,000 hits. And probably an order of magnitude more unused variables that aren't named ignored.

  try (Metrics.newTimer("getOrders")) {
    return db.getOrders();
  }

This doesn't seem to be supported and could cause many issues e.g. if a base interface adds an overloaded method with a similar signature. Suddenly we will have a conflict and compilation issues.

> This JEP would allow stronger static analysis rules like "every declared parameter and variable MUST be used", and _ would serve as the canonical escape hatch for edge cases.

This is a good point. I'm not sure if it's worth the odd syntax and potential misuse but it is interesting.

> This doesn't seem to be supported and could cause many issues e.g. if a base interface adds an overloaded method with a similar signature. Suddenly we will have a conflict and compilation issues.

I think this is already a risk when modifying interfaces or superclasses. For example, if you add a method to a superclass, a subclass might already have a method with the same name/arguments but different return type, which would break compilation.

For those who don't face that issue, life continues as before.

  1> (time-struct-utc (time))
  #S(time year 2023 month 3 day 22 hour 4 min 25 sec 0 wday 3 yday 80 dst nil
          gmtoff 0 zone "GMT")
  2> (match @(struct @type year @y) (time-struct-utc (time))
       (list type y))
  (#<struct-type time> 2023)

  3> (match @(struct @nil year @y) (time-struct-utc (time))
     y)
  2023

  4> (match @(struct foo year @y) (time-struct-utc (time))
       y)
  ** expr-4:1: warning: if-match: no such struct type: foo
  ** match: @(struct foo year @y) failed to match object #S(time year 2023 month 3 day 22 hour 4 min 29 sec 32 wday 3 yday 80
                                                               dst nil gmtoff 0 zone "GMT")

https://www.kylheku.com/cgit/txr/tree/stdlib/match.tl

If a student handed in a pattern matching system that didn't have a "null variable" pattern, I would not award full marks. That's just useless beyond words; you can't do things like

  (match (@a @nil @nil @c) ...)

  1> (compile-toplevel '(match @(struct @type year @y) (time-struct-utc (time))
       (list type y)))
  #<sys:vm-desc: 986dff0>

  2> (disassemble *1)

  data:
      0: year
      1: t
      2: match
      3: @(struct @type year @y)

  syms:
      0: time-struct-utc
      1: time
      2: structp
      3: struct-type
      4: slotp
      5: slot
      6: list
      7: sys:match-pat-error

  code:
      0: 20000003 gcall t3 1
      1: 00000001
      2: 2001000D gcall t13 0 t3
      3: 00030000

      4: 20010002 gcall t2 2 t13
      5: 000D0002

      6: 38000017 if t2 23
      7: 00000002

      8: 20010009 gcall t9 3 t13
      9: 000D0003

     10: 2C0B0009 movsr t11 t9

     11: 20020002 gcall t2 4 t9 d0
     12: 00090004
     13: 00000400

     14: 38000017 if t2 23
     15: 00000002

     16: 20020008 gcall t8 5 t13 d0
     17: 000D0005
     18: 00000400

     19: 2002000C gcall t12 6 t11 t8
     20: 000B0006
     21: 00000008

     22: 1000000C end t12

23 is the error block: run-time function sys:match-pat-error is called with some arguments, like D3, which holds the source code of the pattern.

     23: 20030002 gcall t2 7 d2 d3 t13
     24: 04020007
     25: 000D0403

     26: 10000002 end t2
  instruction count:
     13
  #<sys:vm-desc: 986dff0>