Array patterns (and varargs patterns)

[Ty Young]

On 1/8/21 9: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.
>
>
> I think in the case of the first switch, it was intended to be written 
> like:
>
>
> case String[] { String _, int i = Integer.parseInt(String b) } -> 
> setMultilineLimit(DEPTH, i);
>
>
> Where String _ and String b replaces var _ and var i respectively and 
> a variable is used to store the returned int from Integer.parseInt, 
> which is called i, and passed to setMultilineLimit.
>
>
> setMultilineLimit supposedly accepts an int and if var i, as defined 
> in Brian's example, was meant to be a String, then there is no way 
> that code would have worked unless setMultilineLimit accepted a String 
> and the call to Integer.parseInt was a mistake. Variable i is already 
> defined as a String as it's passed to Integer.parseint, so it can't be 
> reused as an int later. A pure underscore(_) isn't even a valid 
> variable name.
>
>
> It was a really bad example not helped by the variable naming and the 
> use of var, IMO. It is somewhat amusing that JDK developers lecture 
> other people about their variable and method naming yet write names a 
> high school computer science teacher would not find acceptable. var 
> was a bad addition to the language already and its use in code 
> examples and documentation like this really drives that point home.
>
>
> But I digress, pot shots and clapbacks are more meant for social 
> media... although I suspect Brian seems to be the type to just block 
> people on Twitter for disagreements.


So I've been yelled at elsewhere about how rude this seemingly is and, 
in hindsight, it wasn't the best choice of words. I stand by that it's 
somewhat humorous that better variable names were not chosen in 
combination with var given the defense of var in the past, but parts of 
that were not needed. I apologies for that and the comment about 
blocking people, it wasn't needed either.


>
>
>>
>>
>> Regards
>>
>> Swaranga
>>
>>
>> On Wed, Jan 6, 2021 at 8:44 AM Brian Goetz <brian.goetz at oracle.com> 
>> wrote:
>>
>>>
>>>> Other languages have patent matching on head and tail of lists. Adding
>>>> this may mean there should be additional syntax.
>>> I alluded to this in my mail, hoping that people wouldn't allow
>>> themselves to be distracted by this particular siren song:
>>>
>>> <digression>
>>> People are immediately going to ask "can I bind something to the
>>> remainder"; I think this is mostly an "attractive distraction", and
>>> would prefer to not have this dominate the discussion.
>>> </digression>
>>>
>>> The idiom of "match a list by matching (head, tail)", which works great
>>> in Lisp and Haskell, is that (a) the representation of lists in Lisp 
>>> and
>>> Haskell is a cons-cell, and (b) these language have tail-call
>>> elimination, so that processing a list by recursion in this manner is
>>> natural, efficient, and doesn't SOE.  Java has neither of these, so
>>> grafting the illusion of this model when the runtime is not suited 
>>> to it
>>> is just moving the problem one foot down the road, but ultimately is 
>>> not
>>> going to be satisfying.  The performance will be poor, and we'll SOE on
>>> lists longer than a few tens of thousands of elements.
>>>
>>> The bottom line here is that idioms from Language X are very much
>>> connected to _the rest of language X_.  Ignoring this rarely works out
>>> well.
>>>
>>>> Another issue is if the array is shorter say 0 length and one has:
>>>>
>>>>         if (arr instanceof int[] { var a, var b, ... }) { ... }
>>>>
>>>> Will this be an ArrayIndexOutOfBoundException or another exception? If
>>>> it is a reference type `a` and `b` can be null.
>>> No.  Pattern matching is inherently conditional; the match above says
>>> "does `arr` match this array pattern".  Matching the array pattern 
>>> means
>>> being an array, _and_ having the right number of elements, _and_ having
>>> those elements match the nested patterns. Matching should never throw
>>> (though, once we allow users to write patterns that have code in them,
>>> it will be possible to do things like NPE, but those are bugs.)
>>>
>>>>
>>>> On Wed, 6 Jan 2021 at 15:31, Gavin Bierman <gavin.bierman at oracle.com
>>>> <mailto:gavin.bierman at oracle.com>> wrote:
>>>>
>>>>      This is a feature that other languages call an “as pattern”,
>>>>      because you are adding a new pattern variable binding to another
>>>>      pattern (Standard ML used “as”, Haskell uses “@“ but calls it an
>>>>      as pattern). It’s on our list of things to consider; part of the
>>>>      consideration is whether it merits special syntax along with the
>>>>      parsing issues of not having special syntax.
>>>>
>>>>      Gavin
>>>>
>>>>      > On 6 Jan 2021, at 05:44, Suminda Sirinath Salpitikorala
>>>>      Dharmasena <sirinath1978m at gmail.com
>>>>      <mailto:sirinath1978m at gmail.com>> wrote:
>>>>      >
>>>>      > Can we have something like:
>>>>      >
>>>>      >        if (arr instanceof String[] { var a, var b, ... }
>>>>      stringArray) {
>>>>      > ... }
>>>>      >
>>>>      > `stringArray` is optional but if present this will referrer to
>>>>      the whole
>>>>      > array.
>>>>      >
>>>>      >>
>>>>
>>>