Should if|for|while|match statements allow multiline expressions?

[bitwise-aiden]

After shipping this change to match patterns to allow multiline expression in dictionary and array patterns I found another surprising case where I expected multiline:

match some_array: 
  [1, 2, 3],
  [4, 5, 6]:
    do_something()

After some thinking it through it is inline with how if|for|while and even the expression of the match statement behave. Though given there is a clear <keyword> <expression>: or <expression>: pattern for defining these statements does it make sense to keep this constraint / is there any functional reason that we can't open up the parser to allow for multiline expressions in these definitions?

It looks like this has been discussed a bit before specifically for the code that lead me here (#2201), but I think that there may be room for a broader discussion about allowing for this pattern to be consistent across the board. Especially now that you can have pseudo new lines with match statements thanks to my previous PR.

Some of the other examples:

if some_long_predicate || 
    some_other_long_predicate: 
   pass

while some_long_predicate || 
    some_other_long_predicate: 
   pass


# This one seems less valuable, but for consistency may be nice to have.
for value 
  in some_array: 
   pass

[AThousandShips]

For if you have a documented solution:

if a or \
        b:

[bitwise-aiden]

Sorry, I intended to call that out in the original discussion. The intent was to start conversation about the possibility of a pure multiline statement.

As someone that bounces around far too many languages for work and play it has been friction I’ve run up against numerous times when I switch back to GDScript. I’m sure this is similar for anyone coming into it for the first time too.

I was just wanting to know if there is any practical reason the parser doesn’t support it at the moment and if there would be an appetite for updating it.

[AThousandShips]

It does support multiline statements, with continuation, or parentheses, but on its own it wouldn't make sense, it's an indentation based language

Does python support this? Or any other indentation based language?

[bitwise-aiden]

It does support multiline statements, with continuation, or parentheses

Ahh, I don't know how I'd missed parenthesis since it's my go to everywhere else. So then match statement is still a bit of an odd one out in that it doesn't support parenthesis around the whole pattern:

match value: 
    (1, 2): 
        pass

Errors with: Parse Error: Expected closing ")" after grouping expression.

My assumption would be that, with the current parsing, an expression can have parenthesis around it; meeting the , would trigger the error which would fail the parse.

Does python support this? Or any other indentation based language?

Good shout. It's been a little while since I properly used python, so wasn't top of mind. They heavily lean on parenthesis for multiline, so knowing GDScript does too lessens the issue. They do however allow for parenthesis in match patterns, e.g.

match 1: 
    case (1 |
        2): 
      pass

Though does the parse become easier using | instead of ,. Or is that going to require the same handling?

[timothyqiu]

For if and while conditions, I find wrapping them in parentheses looks nicer:

if (
    some_long_predicate or
    some_other_long_predicate
):
    pass

while (
    some_long_predicate or
    some_other_long_predicate
): 
    pass

[bitwise-aiden]

Agreed! This tends to be my default in other languages. I must admit I'd missed this part of the documentation, so most of this discussion is moot.

I think there is still value in adding parenthesis to match statement patterns to have everything inline though.

[dalexeev]

I agree that godotengine/godot#90373 is ok because parentheses are used (whether it's (), [] or {}). Without parentheses, parsing is more difficult for both humans and computers. Especially in the case of incomplete statements or lambdas in expressions.

[bitwise-aiden]

I don't think this is a bug/problem.

I was mentally likening the match pattern to an if statement, but seeing your example I think you're right. In the case of an if statement it is one expression, where as this is multiple joined by a ,.

You are trying to enclose into parentheses several patterns at once, in my opinion this is less readable. Currently the only way to break a line here is to use a backslash between patterns.

Although it isn't as ideal I do think that using parenthesis can be made to look somewhat readable similar to the if statement. I think the issue that I draw with it, especially coming from languages like Python, is that because of the , separator I'm not sure if I read this as one of these constants or all of these constants.

match x:
  (
    MyClass.EnumType.CONSTANT_A,
    MyClass.EnumType.CONSTANT_B,
    MyClass.EnumType.CONSTANT_C,
    MyClass.EnumType.CONSTANT_D
  ): 
    pass

Line breaks on , might make it more legible as pointed out in the issue I linked (#2201), but like you say, that may not be a good idea for parsing. Seems like it would create a one of exception creating an edge case for match statements.

[dalexeev]

The problem is that we've never used parentheses to group multiple statements, just expressions (patterns aren't exactly statements, but pattern list isn't a single expression either). There is some ambiguity about whether parentheses serve to group subexpressions in the expression or patterns in the pattern list.

If we were using case, then perhaps we could use the traditional style (break is not needed, only branches with an empty body are grouped):

match x:
    case MyClass.EnumType.CONSTANT_A:
    case MyClass.EnumType.CONSTANT_B:
    case MyClass.EnumType.CONSTANT_C:
    case MyClass.EnumType.CONSTANT_D:
        pass

Without case this is also possible, but it may be less clear in the case of line breaks or patterns of different lengths.

[bitwise-aiden]

The problem is that we've never used parentheses to group multiple statements, just expressions (patterns aren't exactly statements, but pattern list isn't a single expression either). There is some ambiguity about whether parentheses serve to group expressions or patterns.

+1 I think that using parenthesis may narrow the perspective use cases for the language down the road. Might be safer not to use them for this case.

Without case this is also possible, but it may be less clear in the case of line breaks or patterns of different lengths.

So an empty pattern could assume that it is an additional case for the following pattern?

match x:
    MyClass.EnumType.CONSTANT_A:
    MyClass.EnumType.CONSTANT_B:
    MyClass.EnumType.CONSTANT_C:
    MyClass.EnumType.CONSTANT_D:
        pass

It might help with understanding that they are separate triggers for the block of code, but given that , is already documented as the intended way to have multiple statements this may be the cleanest:

match x:
    MyClass.EnumType.CONSTANT_A,
    MyClass.EnumType.CONSTANT_B,
    MyClass.EnumType.CONSTANT_C,
    MyClass.EnumType.CONSTANT_D:
        pass

Would help with parsing so you don't have to look for another case too. You said before it might not be a good idea; what are some of the issues you foresee with it?

[dalexeev]

what are some of the issues you foresee with it?

1. This is a new way to ignore line breaks. Before this we only used backslashes and parentheses.
2. It is not obvious whether the comma should neutralize just one line break or all whitespace characters up to the next pattern. What about comments?
3. Should we allow an extra comma (followed by a colon)? This is not currently supported for patterns, and probably shouldn't be. However, it is supported in other multiline contexts (function declarations and calls, enumerations, annotations, arrays, and dictionaries).

It might help with understanding that they are separate triggers for the block of code, but given that , is already documented as the intended way to have multiple statements

Yes, but there is already some way. I'm leaning towards #2201, just to point out that if we don't want to introduce new ways to do the same, it's easiest to just leave it as is. Since there's already a way, and it's not so bad:

match x:
    MyClass.EnumType.CONSTANT_A, \
    MyClass.EnumType.CONSTANT_B, \
    MyClass.EnumType.CONSTANT_C, \
    MyClass.EnumType.CONSTANT_D:
        pass

[bitwise-aiden]

1. This is a new way to ignore line breaks. Before this we only used backslashes and parentheses.
2. It is not obvious whether the comma should neutralize just one line break or all whitespace characters up to the next pattern. What about comments?
3. Should we allow an extra comma (followed by a colon)? This is not currently supported for patterns, and probably shouldn't be. However, it is supported in other multiline contexts (function declarations and calls, enumerations, annotations, arrays, and dictionaries).

1. I think this is my biggest concern with it too.
2. Neutralizing just one line break would be the simplest implementation. Though the edge cases would be:

match x: 
    MyClass.EnumType.CONSTANT_A, MyClass.EnumType.CONSTANT_B,
    MyClass.EnumType.CONSTANT_C, # My comment
                                 # <-- Where this is a blank line
    MyClass.EnumType.CONSTANT_D:

• Line with multiple: To replicate current functionality.
• Line with comment: I think in the case of having a comment it makes sense to consume it, as it would be a little harder to understand why that is a parse error compared to the alternative of MyClass.EnumType.CONSTANT_C, \ # My comment (as discussed here being python parity. Although it does still leave situations like this without the ability to comment).
• Blank lines: I could see this being omitted, but might trick some people up.

3. I don't think it needs one given it has the trailing :. It seems rational to omit the final ,. It would be something like (pattern)(, pattern)*: | (pattern):

Yes, but there is already some way. I'm leaning towards #2201, just to point out that if we don't want to introduce new ways to do the same, it's easiest to just leave it as is. Since there's already a way, and it's not so bad:

Absolutely! I definitely didn't intend for this to be a discussion where code needs to ship at the end, just wanted to discuss the edge cases of where the current isn't as good as it could be and if there was room/appetite for any new additions to be considered.

There isn't a clear way forward so I think it's a good outcome to leave things as they are. I really appreciate everyones input in this discussion, it has been supremely valuable. I think it also differs a little from #2201 in that it adds more context to the discussion 👍🏻

Thanks!