Array patterns (and varargs patterns)

[Brian Goetz]

On 1/8/2021 10:22 PM, Ty Young wrote:
>
> On 1/8/21 2:32 PM, Swaranga Sarma wrote:
>> I am a little confused by the expression on the matcher, i.e the
>> Integer.parseInt(var i) - it is not clear what is happening there and I
>> don't think I have seen it before. Can someone explain what is being
>> expressed by that case label? Is it "match a String array with two 
>> elements
>> the second of which is a valid Integer represented as a String value"?
>>
>> Here is the snippet:
>>
>>      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); }
>>
>>      }
>
>
> You aren't alone. People on social media are having trouble figuring 
> out this code too.

And, this is not surprising; this wasn't a message intended for the 
broad public, it was a message within the Expert Group, about a possible 
direction, who has been swimming in these issues for a long time, and 
involving the conjunction of several speculative features.  (Which is an 
important part of the EG discussion; looking down the road at how 
potential features fit together, before making decisions.)  It's fine to 
listen in, but you shouldn't necessarily expect that all the discussions 
will be unpacked for the consumption of casual observers, because that 
was not the audience for this message.   That said, we're usually happy 
to explain when asked constructively (as Swaranga did), though sometimes 
the explanation is still "we don't know yet" or "its probably best to 
wait until XYZ settles down before trying to unpack all this."

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

Nope.  The example was right, and your "corrections" were not. (Which is 
fine; as mentioned above, this is a speculative discussion in the EG 
about the conjunction of a number of features that are still on the 
drawing board.  This was not supposed to be a textbook example, it was 
an example offered in the course of informal discussion, to illustrate a 
specific point, between participants who are well-versed in the domain.)

> It was a really bad example 

Whoa there, cowboy.  Let me explain (again, unfortunately) how this works.

The EG lists are publicly readable, to provide transparency, but it is 
not the case that every message on the EG lists have to be written for 
the audience of casual outside observers -- nor is it reasonable to 
demand, or expect, this to be the case.  If and when we decide to commit 
to this particular constellation of features, a for-a-broader-audience 
explanation will be provided.  (When a feature is ready for broader 
consumption, you see the detail that goes into the writeups, which 
consume a great deal of time and effort.)  Expecting we do so for every 
idea being kicked around the EG would only serve to either (a) slow down 
the process even more, (b) stifle EG discussion, or (c) ensure we only 
discuss things when they are 100% perfect, complete, and written up for 
the least-common-denominator audience.  Neither of these outcomes is 
what you want (and in the case of the latter, you'd surely be screaming 
"behind closed doors") -- so we don't do that.  The cost of this is that 
the EG discussions are ... for the EG.  You are welcome to try and 
follow them, and even ask sensible clarifying questions (as Swaranga 
did), but recognize that you are not the target audience, and that the 
EG discussions have a necessarily different style and focus than "for 
public consumption" communications.  This is the compromise we make when 
we do this work in the open; those who want to listen in can, but should 
recognize that doing so can be hard work, and that they are not 
necessarily the target audience.

For the record, here's what a constructive amber-dev response to 
Swaranga might have looked like (if you still felt the need to respond):

"Brian's example combined a number of speculative pattern matching 
features, some of which have only been discussed on the EG list, so it 
is probably not surprising that seeing them put together for the first 
time was a lot to take in.  There's at least four prospective features 
being used together here: array patterns, nested patterns, unnamed 
(underscore) patterns, and static patterns.  We don't know which of 
these will actually make it into the language, but in this specific 
example, Brian was trying to show how array patterns could combine with 
the other forms of patterns to...."

See the difference?

We welcome constructive engagement, but if you can't contribute 
constructively (and we've had many examples that suggest this is a major 
challenge for you), perhaps the best path is to listen at home, quietly?