Order of evaluation

Order of evaluation is strictly left-to-right, inside-out as it is typical for most others imperative programming languages:

  1. var s = ""
  3. proc p(arg: int): int =
  4.   s.add $arg
  5.   result = arg
  7. discard p(p(1) + p(2))
  9. doAssert s == "123"

Assignments are not special, the left-hand-side expression is evaluated before the right-hand side:

  1. var v = 0
  2. proc getI(): int =
  3.   result = v
  4.   inc v
  6. var a, b: array[0..2, int]
  8. proc someCopy(a: var int; b: int) = a = b
  10. a[getI()] = getI()
  12. doAssert a == [1, 0, 0]
  14. v = 0
  15. someCopy(b[getI()], getI())
  17. doAssert b == [1, 0, 0]

Rationale: Consistency with overloaded assignment or assignment-like operations, a = b can be read as performSomeCopy(a, b).

However, the concept of “order of evaluation” is only applicable after the code was normalized: The normalization involves template expansions and argument reorderings that have been passed to named parameters:

  1. var s = ""
  3. proc p(): int =
  4.   s.add "p"
  5.   result = 5
  7. proc q(): int =
  8.   s.add "q"
  9.   result = 3
  11. # Evaluation order is 'b' before 'a' due to template
  12. # expansion's semantics.
  13. template swapArgs(a, b): untyped =
  14.   b + a
  16. doAssert swapArgs(p() + q(), q() - p()) == 6
  17. doAssert s == "qppq"
  19. # Evaluation order is not influenced by named parameters:
  20. proc construct(first, second: int) =
  21.   discard
  23. # 'p' is evaluated before 'q'!
  24. construct(second = q(), first = p())
  26. doAssert s == "qppqpq"

Rationale: This is far easier to implement than hypothetical alternatives.