Static ifs and identifier resolution

[zagortenay333]

I'm about to add static ifs to my language like the ones Jai and Odin have, and I noticed that there is something rather awkward about their semantics that isn't addressed by you or Jonathan explicitly (that I could find).

Since a static if can inject a variable definition into a scope, it acts as a blocker on identifier resolution. Of course, the identifiers that appear in the static ifs condition cannot be blocked, because the static if could not be resolved at all.

Now, depending on the order in which one atempts to resolve the static ifs, you'll get different outcomes. The problem is exacerbated by having two or more static ifs in the same scope and by allowing forward references of constant local variables.

In the following example the x in the first static if doesn't resolve at all:

package main

main :: proc () {
    when x {}
    when true { x :: true; }
}

But in the following case it does resolve to the x defined in the second static if! The presence of the x in the outer scope causes it to pick up the x in the inner scope which is weird:

package main

import fmt "core:fmt"

main :: proc () {
    x :: false;

    {
        when x { fmt.println("Hello!"); };
        when true { x :: true; }
    }
}

In the following scenario everything resolves:

package main

main :: proc () {
    if x {} // This is a normal if unlike in the first example above.
    when true { x :: true; }
}

The resolution order of static ifs must be defined as part of the language semantics or else different compilers would produce different behaviour, or (worse even) the same compiler could exibit non-deterministic behaviour.

One possible definition would be something like:

1. Place all static ifs within a procedure in a list ordered lexically from top to bottom.
2. Resolve the header of the first static if.
3. Inject the variables of the first static if.
4. Remove the first static if from the list.
5. Prepend any newly injected static ifs to the list.
6. Go to step 2.

Any thoughts?

I compiled the examples above with Odin-0.12.0.

[gingerBill]

Now, depending on the order in which one a[t]tempts to resolve the static ifs, you'll get different outcomes.
Correct, that's why you define the order.

Procedure scopes act very differently to file scopes for numerous reasons.

Currently Odin works like this for procedure scopes:

• Collects scope entities (see: check_collect_entities in checker.cpp) (collection doesn't mean checking)
  • Collect constant declarations first
  • Then collect when statements and evaluate them
  • Collect constant declarations within them
• Start the evaluation at the top and work downwards with constant declarations and (things can still be evaluated out of order here)