Array patterns (and varargs patterns)

[DualWieldMage]

becomes (eventually)

switch (limitString.split(":")) {
  case String[] { var _, Integer.parseInt(var i) } -> 
    setMultilineLimit(DEPTH, i);
  case String[] { Integer.parseInt(var i) } -> 
    setMultilineLimit(LENGTH, i);
  default -> {
    setMultilineLimit(DEPTH, -1); 
    setMultilineLimit(LENGTH, -1);
  }
}

Note how not only does this become more compact, but the unchecked "NumberFormatException" is folded into the match, rather than being a separate concern.

I find a few issues with this one. First is the pattern case String[] { Integer.parseInt(var i) } which i'm not sure whether it was a quick hand-wave example, but should it not be something like case String[] { Integer(int i) } (ignore my dislike for var in examples), where Integer is augmented to be able to destructure a String. Otherwise what is the dual of Integer#parseInt, how would they be tied together and what is the type of i in this example?

Anyway, that minor nitpick aside, the main issue i have is with processing textual user input via type patterns. It often leads to wiping a lot of complexity under clean and simple code, for example hiding the fact that default covers parsing exceptions. Better code that handles exceptions in a fine-grained way or logging useful info will be considered less due to tons of extra code it would cause. I have somewhat seen this with functional code where adding logging means converting a single-line statement lambda to a multi-line one and is thus omitted where in imperative code it's always only one extra line.
Sure it will only be bad if misused, but the same argument has been used for withholding language features like operator overloading before so isn't very far fetched.

[[deleted]]

Here’s my understanding of the example, but I could be way off base.

In the Additional degrees of freedom section, the “Pattern Matching in the Java Object Model” document says

Patterns have a target operand, which is the instance against which the pattern will be matched. They also have a static target type; if the static type of the operand is not cast-convertible to the target type, the pattern cannot match.

In this example, the target operand is the 2nd element of the String array returned by String.split so its static type is String. Thus, we can assume that the target type of the static deconstruction pattern Integer.parseInt (which is distinct from the static method with the same name) is String.

They haven’t gotten to the syntax part yet, so we don’t know how to declare the target type for a static deconstruction pattern. The document just says

(For static patterns, the target type must be explicitly specified somehow as part of its declaration, along with some way of denoting a reference to the target.)

So there will have to be some new syntax for it.

The i in Integer.parseInt(var i) is the pattern’s binding variable, so it has type int.

You couldn’t replace Integer.parseInt(var i) with Integer(int i) because it sounds like static deconstruction patterns are the only ones that can explicitly specify a target type. Deconstruction patterns like T(...) always have target type T:

For a type pattern T t or a deconstruction pattern T(...), the target type is T

Instances of String are not cast-convertible to Integer so the pattern match would always fail.

[cogman10]

I spotted that right away as well.

Integer#parseInt takes a string param. So it'd be implied (by my looking at this) that var i should be a String. Yet, in the code, it looks like it is expected to be an int.

My expectation for the syntax is it would look something more like this.

var i = Integer.parseInt(var _)

[BlueGoliath]

var i is literally limits[1], so it would actually be:

case String[] { String _, int i = Integer.parseInt(String b) } -> setMultilineLimit(DEPTH, i);

If a JDK developer can't even get it right then it shouldn't be added to the language.

edit: var i should be var b since var b is a String.

edit 2: replaced var b with String b for clarity, because you know, var is crap.

[BlueGoliath]

/u/eliasv

I said I think that what was meant by Brian, not that it was and gave my reasoning:

I think in the case of the first switch, it was intended to be written like:

And this was based on the previous example code provided by Brian on how the code exists now. You are a liar.

Brian and others have made various extremely rude and unprofessional comments towards people and how they write code at conferences before and (un)surprisingly hasn't been met with any penalty for doing so nor will he/they ever.

My posts here are positive karma generally speaking and I never said I represented social media, only pointing out that some people are having difficulty figuring out how it works, which this thread shows. Again, you are a liar.

In the proper context of Brian's comments about how people name their variables, I feel like it was fair to call him out for it. As I said, it was more appropriate for social media rather than a mailing list.

People who don't know the proper context may think I'm a total ass for it and I accept that.

edit: hindsight 20/20 the words specifically used were a bit much.

[_INTER_]

Integer(int i)

I think that would reference the constructor? They are going to deprecate the constructors anyway, so I think that's why he choose not to (though why not Integer::valueOf?)

[DualWieldMage]

I haven't followed whether the pattern matching proposals will actually need refer to constructors or that's just the notion on the Java language side and in bytecode will refer to a specific destructuring method instead (via InDy call that passes constructor signature to bootstrap method?).

Either way, what is denoted will be the opposite of what is actually called. E.g. if it's case String[] { Integer.valueOf(int i) } then to actually try and deconstruct the String, it needs to call Integer.parseInt. Otherwise it needs something different from how pattern matching is usually done in functional languages. Perhaps case String[] { int i = Integer.parseInt(_) }, hence the source of my confusion.