SIP-74 Allow Partial Function Literals to be defined with Parentheses

[lihaoyi]

No description provided.

[odersky]

Other than my comment on multiple cases inside parentheses I like the proposal. It's already implemented as part of #23821.

[odersky]

I'd like to push back on this aspect of the proposal (the rest is great!). We do not allow multiple statements between parentheses, and for good reason, since some of the logic around newline insertion/indentation relies on this. For consistency, we should not allow multiple cases either. I see no good reason to allow it. The code does not become clearer if we do.

[bjornregnell]

Agree!

[lihaoyi]

The argument for multiple cases within parens is that curlies are normally needed for multiple sequential semicolon-separated statements, but you can have multiple cases on a single line without semicolons:

foo.map{ case true => 1 case false => 2 }

By that logic, multiple cases aren't really "statements" in the same way e.g. multiple printlns would be, and so it makes sense that they wouldn't need curlies to allow multiple in the same expression

[odersky]

Technically that's a valid argument, but cases are still multiple things that should not be grouped in parens. More reasons why:

• this looks bad and we should not encourage that style.

• there are subtle rules on newline insertion and indentation that depend on not being enclosed by parens. They might cause subtle problems here. I don't want to have to think about these problems or fix bugs if they come up.

[odersky]

For the case of single cases inside parentheses or at the top-level the syntax change is one line in the production of Expr. This is currently:

Expr              ::=  FunParams (‘=>’ | ‘?=>’) Expr  
                    |  TypTypeParamClause ‘=>’ Expr     
                    |  Expr1 

The SIP adds one more alternative:

Expr             ::= ...
                   |  ExprCaseClause           

ExprCaseClause already exists, it is defined like this:

ExprCaseClause    ::=  ‘case’ Pattern [Guard] ‘=>’ Expr

Maybe this can be integrated in the SIP?