That’s the point, you’re just haggling about scopes now. All the way from being new per program invocation to new per loop.

Immutability doesn’t have this connotation.

How? I think the same argument applies: If it's changing from loop to loop, seems mutable to me.

I can give a specific example.

    for (0..5) |i| {
        i = i + 1;
        std.debug.print("foo {}\n", .{i});
    }

In this loop in Zig, the reassignment to i fails, because i is a constant. However, i is a new constant bound to a different value each iteration.

To potentially make it clearer that this is not mutation of a constant between iterations, technically &i could change between iterations, and the program would still be correct. This is not true with a c-style for loop using explicit mutation.

I argue in your example there are 6 constants, not 1 constant with 6 different values, though this could be semantics ie we could both be right in some way

Exactly. As said higher in this comment chain:

> So, constant, but repeatedly redefined.

it was constant if it could have been redefined, by the basic definition of what constant means. so no, not constant, but constants

I think you’re after something other than immutability then.

You’re allowed to rebind a var defined within a loop, it doesn’t mean that you can’t hang on to the old value if you need to.

With mutability, you actively can’t hang on to the old value, it’ll change under your feet.

Maybe it makes more sense if you think about it like tail recursion: you call a function and do some calculations, and then you call the same function again, but with new args.

This is allowed, and not the same as hammering a variable in place.

No? It has a lifetime of one loop duration, and is constant during that duration. Seems perfectly fine to me.