Currently the Zig master documentation section on recursion points to the 0.3.0 Release Notes, which are incredibly out of date with regards to Zig's approach to recursion -- it refers to @newStackPointer, which was removed in release 0.6.0 (although this information has to be hunted down)
The 0.6.0 release notes indicate that async functions are the "new strategy for recursion", but doesn't expand upon this further.
From my research, the current preferred strategy for recursion is heap-allocating your frames explicitly as per follows:
fn fact(ally: std.mem.Allocator, n: usize) error{OutOfMemory}!usize {
switch (n) {
0 => return 1,
else => {
const frame = try ally.create(@Frame(fact));
defer ally.destroy(frame);
frame.* = async fact(ally, n - 1);
return n * try await frame;
},
}
}While the recursion section states that "Recursion is an area of active experimentation in Zig and so the documentation here is not final." which is correct, it pointing to the 0.3.0 Release Notes IMO can be considered incorrect at this point as the 0.3.0 release notes are quite out of date on the topic.
Currently the Zig master documentation section on recursion points to the 0.3.0 Release Notes, which are incredibly out of date with regards to Zig's approach to recursion -- it refers to
@newStackPointer, which was removed in release 0.6.0 (although this information has to be hunted down)The 0.6.0 release notes indicate that async functions are the "new strategy for recursion", but doesn't expand upon this further.
From my research, the current preferred strategy for recursion is heap-allocating your frames explicitly as per follows:
While the recursion section states that "Recursion is an area of active experimentation in Zig and so the documentation here is not final." which is correct, it pointing to the 0.3.0 Release Notes IMO can be considered incorrect at this point as the 0.3.0 release notes are quite out of date on the topic.