nnkDo node disappears when it has no arguments

[krux02]

In the untyped ast, a node of nnkDo with no arguments is omitted. This makes it indestinguishable from a stmtListExpr without a do block.

Example

import macros

dumpTree:
  foobar("abc") do:
    echo 1

  foobar("abc") do(abc):
    echo 1

  foobar("abc", proc() = echo 1)

Current Output

StmtList
  Call
    Ident "foobar"
    StrLit "abc"
    StmtList
      Command
        Ident "echo"
        IntLit 1
  Call
    Ident "foobar"
    StrLit "abc"
    Do
      Empty
      Empty
      Empty
      FormalParams
        Empty
        IdentDefs
          Ident "abc"
          Empty
          Empty
      Empty
      Empty
      StmtList
        Command
          Ident "echo"
          IntLit 1
  Call
    Ident "foobar"
    StrLit "abc"
    Lambda
      Empty
      Empty
      Empty
      FormalParams
        Empty
      Empty
      Empty
      StmtList
        Command
          Ident "echo"
          IntLit 1

Expected Output

StmtList
  Call
    Ident "foobar"
    StrLit "abc"
    Do
      Empty
      Empty
      Empty
      FormalParams
        Empty
      Empty
      Empty
      StmtList
        Command
          Ident "echo"
          IntLit 1
  Call
    Ident "foobar"
    StrLit "abc"
    Do
      Empty
      Empty
      Empty
      FormalParams
        Empty
        IdentDefs
          Ident "abc"
          Empty
          Empty
      Empty
      Empty
      StmtList
        Command
          Ident "echo"
          IntLit 1
  Call
    Ident "foobar"
    StrLit "abc"
    Lambda
      Empty
      Empty
      Empty
      FormalParams
        Empty
      Empty
      Empty
      StmtList
        Command
          Ident "echo"
          IntLit 1

Additional Information

This issue is related: #12110

[mratsim]

But isn't that a feature? I depend on that on many of my macros.

[krux02]

Well, technically speaking, the do node kind is stripped and the do lambda expression is converted into just a stmtList, then later during compilation, when a parameter of type proc(): void is expected, any stmtList is lifted automatically into a lambda expression again. You probably already know that we don't like implicit conversions. I am sorry that changing this behaviour would break your code. The minimun that I can assure you is if this gets changed is, the changes required would be easy to spot, straight forward to change and compatible with old versions of Nim. This is what I have in mind is that you inject these calls into your code where a do block is possible:

proc stripDoNode(arg: NimNode): NimNode =
  if arg.kind == nnkDo: # nnkDo is structurally identical to nnkLambda
    return arg[6]
  else:
    return arg # old version of nim that auto strips do blocks.

The reason I see this as a bug and not a feature is, the do is explicity written out in the source code, it is documented as an official way to write lambda expressions. How should people know that this relies on an implicit conversions? This nkDo should simply be visible in untyped AST nodes.

[mratsim]

It sounds good but from a backward compat point of view, a flag --nimOldDoNotation would be ideal.

Assuming a package provided a macro

macro foo(arg0, arg1, arg2: untyped): untyped =
  discard

Maybe the author expected everyone to use it like foo(1, 2, 3) but maybe some user used:

foo(1):
  2
do:
  3

I'm pretty sure the do notation is not that popular but an escape hatch for users stuck with an unupdated library would be good.

[krux02]

@mratsim That one is planned for every breaking change in the language from now on.

[metagn]

the do is explicity written out in the source code, it is documented as an official way to write lambda expressions.

Just do: by itself is now documented to always mean a statement list https://nim-lang.org/docs/manual.html#procedures-do-notation, other discussion here nim-lang/RFCs#486, closing as intended