Unify grammar for "blocks"

[matklad]

fn main() {
    try { 92 };
    async { 92 };
    unsafe { 92 };
}

FN_DEF@0..66
  FN_KW@0..2 "fn"
  WHITESPACE@2..3 " "
  NAME@3..7
    IDENT@3..7 "main"
  PARAM_LIST@7..9
    L_PAREN@7..8 "("
    R_PAREN@8..9 ")"
  WHITESPACE@9..10 " "
  BLOCK_EXPR@10..66
    BLOCK@10..66
      L_CURLY@10..11 "{"
      WHITESPACE@11..16 "\n    "
      EXPR_STMT@16..27
        TRY_EXPR@16..26          <- TryExpr
          TRY_KW@16..19 "try"
          WHITESPACE@19..20 " "
          BLOCK_EXPR@20..26
            BLOCK@20..26
              L_CURLY@20..21 "{"
              WHITESPACE@21..22 " "
              LITERAL@22..24
                INT_NUMBER@22..24 "92"
              WHITESPACE@24..25 " "
              R_CURLY@25..26 "}"
        SEMICOLON@26..27 ";"
      WHITESPACE@27..32 "\n    "
      EXPR_STMT@32..45
        BLOCK_EXPR@32..44          <- Block
          ASYNC_KW@32..37 "async"
          WHITESPACE@37..38 " "
          BLOCK@38..44
            L_CURLY@38..39 "{"
            WHITESPACE@39..40 " "
            LITERAL@40..42
              INT_NUMBER@40..42 "92"
            WHITESPACE@42..43 " "
            R_CURLY@43..44 "}"
        SEMICOLON@44..45 ";"
      WHITESPACE@45..50 "\n    "
      EXPR_STMT@50..64
        BLOCK_EXPR@50..63          <- Block
          UNSAFE_KW@50..56 "unsafe"
          WHITESPACE@56..57 " "
          BLOCK@57..63
            L_CURLY@57..58 "{"
            WHITESPACE@58..59 " "
            LITERAL@59..61
              INT_NUMBER@59..61 "92"
            WHITESPACE@61..62 " "
            R_CURLY@62..63 "}"
        SEMICOLON@63..64 ";"
      WHITESPACE@64..65 "\n"
      R_CURLY@65..66 "}"

One of these is not like the others... I think we should get rid of try expression, syntactically, the all look like blocks with modifiers.

[matklad]

Lol, apparently we have both TryExpr and TryBlockExpr...

[matklad]

Hm, I am on the fence as to which direction we should go actually.

1. One way is to say that a BlockExpr consist of a Block and optional modifier (try, async, unsafe).

   BlockExpr
     'try'
     Block
       '{'
         Expr
       '}'
   

2. A different way is to say that BlockExpr and Block are just the same thing, but that we also have AsyncExpr, UnsafeExpr and TryExpr

   TryExpr
     'try'
     BlockExpr
       '{'
         Expr
       '}'
   

We currently do

TryExpr
  'try'
  BlockExpr
    Block
      '{'
        Expr
      '}'

We are currently close to 1) rather than 2). I think I like 2) more, because it makes things like fn foo() unsafe {} or if true try { this } impossible. OTOH, "syntax" of async {}, try {}, and unsafe {} is exactly the same, so it doesn't make sense to burn three AST nodes just for them.

If we go all the way to the logical completness, I imagine we can have EffectExpr, where Effect is one of try,async,unsafe?

EffectExpr
  'try'
  BlockExpr
    '{'
      Expr
    '}'

@flodiebold wdyt?

[flodiebold]

Hmm to me 1) feels more correct, because the {} in try {} isn't really a stand-alone expression (just part of it). Maybe fn foo() {} should just use a Block directly and not a BlockExpr? I.e. BlockExpr would only be in places where any expr could be.

OTOH EffectExpr would also be fine.

[matklad]

Yeah, that was my thinking as well, but then I realized that try Some(None?) is also imaginable.

Maybe fn foo() {} should just use a Block directly and not a BlockExpr?

I believe I've actively refactored that out some time ago :-) It was inconvenient during lowering where consts and functions bodies would be different. Having if whose branches are not expressions was also awkward.

I guess, I just want to argue that EffectExpr is the right solution :-)

[matklad]

🤦 🤦 🤦 🤦 🤦 🤦 🤦 🤦 🤦 🤦 🤦 🤦 🤦 🤦 🤦 🤦 🤦 🤦 🤦 🤦 🤦 🤦 🤦 🤦 🤦 🤦 🤦 🤦 🤦 🤦 🤦

Lol, apparently we have both TryExpr and TryBlockExpr...

Like, of course, because one is expr? and another is try {}. And I've merged them...
Need more tests

🤦 🤦 🤦 🤦 🤦 🤦 🤦 🤦 🤦 🤦 🤦 🤦 🤦 🤦 🤦 🤦 🤦 🤦 🤦 🤦 🤦 🤦 🤦 🤦 🤦 🤦 🤦 🤦 🤦 🤦 🤦

[matklad]

#4257 implements the effect expression idea. I think I like this approach, but I won't be mering this right away to avoid 🤦 :)