Patterns and arguments

[Brian Goetz]

This is a fair question, and the observation that “it can be hard to tell input arguments from nested patterns” is obviously a valid one, but this is a syntax issue.  One of the reasons I deliberately chose to minimize syntax examples in my document is that I didn’t want to get distracted on this.  So yes, this is a good question, there’s a good discussion to be had, but I would prefer not to have it now.  I have a proposal in mind but the time is not yet right, so I have held it back.  

Now, you might ask, why did I even bring up input arguments then?  Because it is a critical part of the model; we are going to need patterns that take inputs (think Map::get or regex.)  So it has to be on the table as something the model must support.  But I don’t want to confront syntax — either use site or declaration site — yet.  

> On Jan 18, 2021, at 10:59 AM, Remi Forax <forax at univ-mlv.fr> wrote:
> 
> I think we should take a look to the difference between (sub-)patterns and arguments of a pattern.
> 
> If i want to test if o is a String with an integer value greater than 10, i can write something like
>  switch(o) {
>    case String s && Integer.parseInt(s, >10) -> ...
>  }
> 
> but this pseudo syntax is not a good one because it's like the argument of the pattern (s) and the sub-pattern (>10) are both "arguments" of the pattern Integer.parseInt.
> 
> For the shake of the demonstration, let's use a syntax that cleanly separate the arguments from the sub-pattern,
> with the arguments in between '{' '}' and the sub-pattern in between '[' ']'
> 
>  switch(o) {
>    case String s && Integer.parseInt{s} [>10] -> ...
>  }
> 
> I think it's important to separate the two because they don't obey the same rules,
> the arguments can be any expressions while the sub-pattern can only be a pattern.
> 
> By example, Foo.bar{1}[...] is valid while Foo.bar{...}[1] is not (with ... meaning whatever works).
> Because 1 is a valid argument while 1 is not a valid pattern.
> 
> If we separate the arguments and the pattern, this has several implications
> - until now, we have used parenthesis as patterns separator, but given that we has used parenthesis for arguments since Java 1.0,
>  we may want to revisit the use of parenthesis for the sub-patterns
>  - we can also use parenthesis for both but it may be confusing.
> - we may not need 'var' because it can only appear in the sub-pattern part, may be the fact that there is a specific delimiter for that part is enough.
> 
> Rémi