Unclear compile time variable scoping rules

[lerno]

If we have the following code:

fn foo(num: i32) i32
{
    return num + 1;
}

export fn bar(num: i32) i32 
{
    comptime var i : i32 = 0;
    i = i + 1;
    if (num > 2)
    {
        i = i + 2;
        var x : i32 = foo(i);
    }
    else
    {
        i = i * 2;
        var x : i32 = foo(i);
    }
    i = i + 10;
    return foo(i);
}

Inspecting the LLVM output in 0.6.0, we note that foo is called with values 3, 6 and 16 respectively. There is a certain sense to this. The function will return 17 regardless of input. However if we change the code to this way:

export fn bar(num: i32) i32 
{
    comptime var i : i32 = 0;
    i = i + 1;
    if (false)
    {
        i = i + 2;
        var x : i32 = foo(i);
    }
    else
    {
        i = i * 2;
        var x : i32 = foo(i);
    }
    i = i + 10;
    return foo(i);
}

Suddenly the function returns 13.

This seems like something that could be extremely bug prone.

Possible alternatives:

1. Make it an error to change a comptime in a deeper scope (i.e. both examples are considered invalid)
2. Make it an error to change a comptime in a deeper scope if it cannot be flattened to a singly directed graph (makes the first example invalid)
3. Altering a comp time variable in a deeper scope creates a copy (so in our example the function would return 11 for both examples.

[lerno]

It seems that this behaviour was documented earlier, for example in #906 and #1470. #1470 appears to suggest (1), but perhaps (2) is more attractive as it would allow more complex uses of compile time variables. (3) produces the best results for some cases, but is more difficult to reason about when there are compile time loops.

[ghost]

I think it's important to allow branching on compile time conditions. Your second code example should be allowed. But in your first code example, it definitely feels sketchy to allow an outer comptime variable to be mutated in a runtime conditional scope.

[lerno]

@dbandstra It's slightly working against Zig here that there is no specific code to make the if-statement compile time. If the code had looked like this:

inline if (false)
{
   i = i + 2;
   var x : i32 = foo(i);
}

Then we could contrast that with this:

if (false)
{
   i = i + 2; // Compile time error
   var x : i32 = foo(i);
}

So essentially only allow the modification if it is in a compile time branch.

[andrewrk]

there are several issues open about this. here are some off the top of my head:

• Meta-proposal: Comptime memory management reform #5895
• pointers to "comptime mutable" data should be const pointers outside the comptime scope #1487
• compile error for modification of comptime data inside runtime block #1470

[lerno]

@andrewrk Which issue is appropriate to track if I want to see what happens with this particular issue?