#What's the simplest way to make a for loop for x amount of iterations?

1 messages · Page 1 of 1 (latest)

outer nimbus
#

Say I have a variable var amount: u8 = 5;

I want to do something amount times, but I am having a hard time figuring out how to do that in Zig.

var index: u8 = 0;
while (index < amount) : (index += 1) {
  // do stuff
}

this seems to work but it feels extremely cumbersome. is there a shorter way to do this?

worn vine
#

that's the only proper way at the moment

#

at some point we will have syntax for for (n..m) |i| though

#

in the meantime, there's also a cursed version

#
fn voidArr() [*]void {
    return undefined;
}

test {
    for (voidArr()[0..amount]) |_, index| {
        _ = index;
    }
}
#

I don't recommend using it

#

but I also don't not recommend using it

outer nimbus
outer nimbus
worn vine
#

yes, quite so

#

though, for a long time the consensus

#

was that it wasn't

#

it only changed within the last year because it was accepted as a side-feature for another one, which it elevates

outer nimbus
#

i see. is there a github issue that tracks the discussion?

worn vine
#

otherwise, the general sentiment was that var i: usize = 0; while (i < x) : (i += 1) {...} was good enough

#
GitHub

for (a...b) |x, index| { ... } Where a and b can be chars, integers, anything that can define a range. This is also better syntax IMHO than: {var i = 0; while (i < n; i += 1) { ... }}

GitHub

Say I have some large arrays of the same size, and I want to perform some element-wise operation on them. In status quo, that might look like this: const doSomething = fn (c: *[1024]u32, a: [1024]u...

#

these are the two relevant issues

#

the first one is technically rejected

#

but it is in a way, un-rejected in the subsequent issue, during some design bikeshedding

outer nimbus
#

my main issue with the current way is not only that it's verbose but that i have to manually reset my index variable AFTER the loop

#

(if i want to do e.g. another loop right after)

worn vine
#

yes, yes, I know, this is a tired conversation

#

there's lots of arguments for and against

#

point is though, that it's a settled matter

outer nimbus
#

okay, thanks. will read those issues then 🙏

#

oh wow, so it looks like this syntax would become possible then

for (0..10) |i| {
    // ...
}

seems super clean, love it! ❤️

worn vine
#

aye, that it will

#

just a matter of waiting for it to be implemented

untold silo
#
for (array[0..5]) |_| {
    // ...
}
untold silo
worn vine
# untold silo Or is that improper?

that will issue an out of bounds error, unless you do something like what I demo'd before, with a void many item pointer. That's safe since loads and stores on 0-sized values never actually generate code

#

or wait, you mean with an array that's large enough

#

I mean, that's a solution, but it certainly leaves much to be desired

#

you end up allocating a bunch of stack or static memory just to do a loop, and you're constrained to the bounds of that particular array, meaning if you have a dynamic bound you can never be certain the program will run correctly

#

the needless allocation issue is solved by using a 0-sized item like void, and then you can solve the bounds problem by just not having one in the first place, with a many item pointer

untold silo
#

Thanks for explaining, if you have a large array anyway, would this still cause allocation issues?

worn vine
#

I mean, if you already happen to have a large array, then that's not an allocation issue, that's just already having allocated a lot of memory. The issue I pointed out was that doing so just to do a ranged for loop is very wasteful.

untold silo
#

Good, I did think of that when I said can use any array with larger length. Thanks for clarifying!

untold silo
worn vine