Proposal: A New redefer Keyword for Function-Scoped Deferred Execution

wujilingfeng · February 5, 2026, 2:23am

I would like to propose the introduction of a new keyword in Zig: redefer. Its purpose would be to push a block of code onto a LIFO stack for execution when the function scope is exited, whether through a return, a try, or by reaching the end of the function body.

Many of the current challenges in Zig concerning memory management and logical correctness stem from the lack of a dynamic, deferred execution mechanism that pairs seamlessly with return-based control flow. While the existing defer keyword is excellent for block-scoped cleanup (reacting to continue or break), it falls short when dealing with function-level resource management, especially in dynamic scenarios like loops. This inadequacy often leads to subtle and dangerous bugs latent in Zig code.

In fact, errdefer can be seen as a special case of the proposed redefer. The underlying behavior of the try keyword is effectively a return from the current function. Therefore, redefer could completely subsume the functionality of errdefer, allowing for more complex logic by inspecting the return value if needed. Of course, given the convenience of the try keyword, it would still be valuable to keep errdefer as a more concise syntactic sugar for the error path（Because the try statement does not explicitly catch errors）.

Consider the following well-known example in the Zig community, which has a serious memory leak issue:

var a = try allocator.alloc([]f64, 2);
errdefer allocator.free(a);
for (0..2) |i| {
    a[i] = try allocator.alloc(f64, 2);
}
defer {
    for (a) |row| allocator.free(row);
}

If the second alloc call fails, a memory leak is guaranteed. Implementing the correct cleanup logic for all failure paths using only defer and errdefer becomes exceptionally complex and unwieldy. This not only reduces development productivity but also explains why this pattern of potentially unsafe code is prevalent across many Zig projects.

With the proposed redefer keyword, the solution becomes elegantly simple:

var a = try allocator.alloc([]f64, 2);
defer allocator.free(a);
for (0..2) |i| {
    a[i] = try allocator.alloc(f64, 2);
    redefer allocator.free(a[i]);
}

Furthermore, the addition of redefer would enable a powerful “side-effect-free” programming style. It’s common for a function to accept a container or a pointer and temporarily modify the data it points to for performance or algorithmic reasons. However, developers often forget to restore the data to its original state before returning, leading to subtle bugs when the modified data is used elsewhere. These types of logical errors can be notoriously difficult to debug.

With redefer, we can schedule the data to be restored immediately after it is modified, ensuring the function is free of side effects from the caller’s perspective. This can be achieved with minimal code overhead.

fn processData(data: []u8) void {
    const original_byte = data[0];
    {//Simulate a scope
      data[0] = 0; // Temporary modification for processing
      redefer data[0] = original_byte; // Guaranteed restoration on function exit
    }
    // ... complex logic that might return early ...
}

I believe this feature would significantly enhance the safety and stability of Zig code while preserving its performance, by providing a robust and intuitive tool for managing resources and state across the entire function’s lifecycle.

marler8997 · February 5, 2026, 3:24am

As for the sequence issue you mentioned, of course it’s a first in, last out, which shouldn’t be a problem, right？

If that’s the case then you’ve introduced some “weirdness”. Take this example:

defer foo();
redefer bar();

What executes first, foo or bar? We actually don’t have enough information to tell. If this code appears at the top-level of a function, then it will be bar then foo (LIFO order). However, if this appears inside a block like this:

fn func() void {
    {
        defer foo();
        redefer bar();
    }
}

Now in this case the order will be foo then bar. Having the order of deferred execution depend on which level of a function the code exists is the footgun I was referring to. In your code example, if your code appeared anywhere other than the top-level, it would have reversed the cleanup order and you’d have a bug.

Because of this, I was thinking you might have been proposing the alternative, where you always execute all defers and then finish with all the rdefers, but in that case your code example would be broken from the get-go. So, I’m actually not sure how you were wanting this to behave and…I’m not sure how you could even fix your example to work correctly.

wujilingfeng · February 5, 2026, 2:44am

To achieve the functionality of this keyword, it seems that it also involves capturing local scope variables.

marler8997 · February 5, 2026, 2:59am

With the proposed redefer keyword, the solution becomes elegantly simple:

It’s not clear whether your example is correct. If your code is inside a block, then the container array gets freed before the inner arrays (since defer would run at the end of the block but redefer runs at the end of the function.

Having a different kind of defer seems like it could be a footgun. You can also simulate what your proposed redefer does today with something like this:

// put this at the top of the function
var foo: ?T = null;
defer if (foo) {
    // do cleanup
}

// ...later on in the function

foo = ...; // equivalent to rdefer

Implementing the correct cleanup logic for all failure paths using only defer and errdefer becomes exceptionally complex and unwieldy.

Here’s my attempt:

    var al: std.ArrayListUnmanaged([]f64) = .{};
    defer al.deinit(allocator);
    errdefer for (al.items) |row| {
        allocator.free(row);
    };
    try al.ensureTotalCapacity(allocator, 2);
    for (0..2) |_| {
        al.appendAssumeCapacity(try allocator.alloc(f64, 2));
    }

This should behave correctly and even does so if it’s inside a block.

P.S. actually your example may not be correct even if it’s not inside a sub-block. It would depend on if defer’s and rdefer’s get executed in the same reverse order, or if you first execute all defers and then all rdefers…if it’s the latter then example would still be incorrect.

wujilingfeng · February 5, 2026, 3:10am

I don’t quite understand your first paragraph. In your second paragraph, the solution you provided actually relies on many implicit conditions. In fact, as long as I make slight changes to the requirements and logic, your method will become ineffective. Because fundamentally, to keep code concise, it is necessary to have a corresponding defer statement with the return statement. Secondly, the method you provided is not obviously more lengthy than the redefer method, which is a problem that developers can easily cause.
As for the sequence issue you mentioned, of course it’s a first in, last out, which shouldn’t be a problem, right？

I seem to understand what you mean, you seem to have ambiguity in very details (which I think are irrelevant because they are simple), and then question the entire direction. I don’t want to argue about the details anymore because they are too simple and I thought they didn’t need attention.

npc1054657282 · February 5, 2026, 3:24am

The issue you mentioned theoretically exists, but your solution has potential risks. Please see the function below. Since redefer executes whenever a function scope encounters an error, regardless of the timing, here at try bar();, redefer will still be triggered even if the lifetime of a has ended.

fn foo() !void {
    blk: {
        var a = try allocator.alloc([]f64, 2);
        errdefer allocator.free(a);
        for (0..2) |i| {
            a[i] = try allocator.alloc(f64, 2);
            redefer allocator.free(a[i]);
        }
        defer {
            for (a) |row| allocator.free(row);
        }
    }
    try bar();
}

Edit:
If your redefer is strictly limited to the ‘errdefer of the entire loop level’ rather than the ‘function-level errdefer,’ it might be feasible. One possible translation is as follows:

    var a = try allocator.alloc([]f64, 2);
    errdefer allocator.free(a);
    var i, const maybe_err = blk: {
        for (0..2) |i| {
            a[i] = allocator.alloc(f64, 2) catch |err| break :blk .{ i, err };
        }
        break :blk .{ undefined, {} };
    };
    maybe_err catch |err| {
        while (i > 0) {
            i -= 0;
            allocator.free(a[i]);
        }
        return err;
    };

    defer {
        for (a) |row| allocator.free(row);
    }

However, in order for it to always translate correctly and feasibly within loops, I think it would at least require support at the language level for things like reverse iterators. In simple range-based for loops, the problem is not as obvious.

wujilingfeng · February 5, 2026, 3:28am

what are you saying?Do you want to blame the logical problem on keywords? Do you want to use a mistake to deny the person who provided the tool?

andrewrk · February 5, 2026, 3:31am

github.com/ziglang/zig

un-defer, re-defer, defer.is_active

opened 09:01AM - 13 Sep 17 UTC

closed 06:44PM - 19 Oct 17 UTC

PavelVozenilek

enhancement breaking proposal

`defer` feature was initially invented in year 2000 by Andrei Alexandrescu and P…etru Marginean, under name `scope guard`. ( http://www.drdobbs.com/cpp/generic-change-the-way-you-write-excepti/184403758 ) Alexandrescu later introduced it into D language, in three forms, no less. Language Go brought up keyword `defer`. ------------------ Say we have a connection, want to close it at the end of lexical block, but it can be closed only _once_. Solution is simple, use a helper flag: ``` { connection = open_connection(); bool do_not_do_this = false; defer if (!do_not_do_this ) close_connection(connection); ... if (error_occured_and_connection_selfclosed) do_not_do_this = true; ... } ``` Though simple it has some problems: 1. `defer` is high level functionality, fiddling with a flag is the lowest possible level. 2. The intention (to cancel `defer`) is hidden. 3. If the function is complicated and already has lot of local variables adding a flag makes things worse. My suggestion is to provide the inversion to `defer `as language feature: ``` { connection = open_connection(); defer close_connection(connection); ... if (...) un-defer; ... } ``` or named alternative: ``` { connection = open_connection(); const closer = defer close_connection(connection); ... if (...) un-defer closer; ... } ``` No easy to misuse helper flags anymore! Notes: 1. The name `un-defer` contains minus. Why not? It is more readable. 2. Multiple named defers are possible. 3. Anonymous `un-defer` could be used only in case when there's just single unnamed `defer`, otherwise name is required. ------------------ It is possible to go even further and add `re-defer` functionality. ``` { transaction = begin_transaction(); defer commit(transaction); ... if (...) re-defer rollback(transaction); ... } ``` or similarly named variant. Notes: 1. Notes for `un-defer` are also valid here. 2. It is possible to combine `un-defer` and `re-defer` in any way. -------------------- As things grew complicated support for `assert` could be added: ``` { connection = open_connection(); defer close_connection(connection); ... if (...) { un-defer; assert(defer.is_active == false); } else { assert(defer.is_active == true); } } ``` Named variant: ``` { connection = open_connection(); const closer = defer close_connection(connection); ... if (...) { un-defer closer; assert(closer.is_active == false); } else { assert(closer.is_active == true); } } ``` Notes: 1. This feature should be allowed only inside `assert`. Making it general would open Hell's gate. ------------------- To support `re-defer` there could be some way to print current defer action as a string (string with code inside) in debugger and/or IDE.

wujilingfeng · February 5, 2026, 3:32am

I am too tired to answer some meaningless questions. Looking forward to better safety and stability for Zig. Wishing you all the best.

wujilingfeng · February 5, 2026, 7:51am

In engineering practice, redefer only supports integer for() loops and is restricted to capturing the index variable i. Within an if statement, redefer can only capture the boolean value of the current block’s condition. These limitations make backend optimization straightforward. In reality, what is pushed onto the stack is not the local variable itself. Instead, under these constraints, the backend effectively re-executes the for loop’s traversal and the if check. As a result, the required stack space is known at compile time.

This principle also holds true for nested loops under these restrictions. In fact, no new backend compilation code is required. redefer can simply be treated as syntactic sugar for defer, by directly translating redefer statements into defer statements at compile time.

invlpg · February 5, 2026, 9:32am

redefer as you describe it would allow for unbounded stack growth (your LIFO is about as safe as a VLA), which would conflict with the following proposals:

github.com/ziglang/zig

safe recursion

opened 03:12AM - 11 May 18 UTC

andrewrk

proposal accepted

[Accepted Proposal](https://github.com/ziglang/zig/issues/1006#issuecomment-5346…60820) ----- If we solve #157 then we'll know at compile-time the maximum stack usage of the entire call graph. Except for recursion. Recursion - whether direct or indirect - represents a loop in the graph. ![directed_graph _cyclic svg](https://user-images.githubusercontent.com/106511/39903747-c0e3d478-54a2-11e8-81ce-4024db1846f4.png) Here you can see indirect recursion `B->C->E->D->B...` Recursion is problematic because it can happen a number of times that is only known at runtime, whereas the stack size is determined at compile-time. If too much recursion happens, we get stack overflow. Apart from being an annoying bug, stack overflow is a real concern for embedded software, which typically must resort to heuristics to find out just how small of a stack size they can get away with using. But recursion is very useful. It's an intuitive way to reason about control flow. @Hejsil wrote zig's self-hosted parser without recursion, and it is not as straightforward as recursive programming. So what do we do? We have our cake and eat it, too. That's what we do. Looking at the graph above again, we can have every function call in the graph be normal, except for D calling B. That's the only entrance into the cycle. So we can make there be a compile error for a normal function call from D to B. To make a function call which starts a cycle, you have to use a builtin: ```zig const new_stack = try allocator.alloc(u8, @stackSize(function)); defer allocator.free(new_stack); _ = @recursiveCall(new_stack, function, args); ``` It is a compile error to use `@recursiveCall` when you could have used a normal function call, and it is a compile error to use a normal function call when you must use `@recursiveCall`. So the compiler always tells you what to do. I've prototyped how this would be emitted to LLVM using inline assembly, and I am talking to the LLVM mailing list to find out what's the best way to accomplish this. http://lists.llvm.org/pipermail/llvm-dev/2018-May/123217.html There's another, simpler way we can have safe recursion, by limiting the amount of recursion at compile-time. This would be another builtin, that would look like this: ```zig var cycles_left: usize = undefined; _ = @limitedRecursiveCall(999, &cycles_left, function, args); if (cycles_left == 0) @panic("recursion limit exceeded"); ``` This would work the same way except instead of allocating memory on the heap, we specify the maximum number of cycles, and the function call fails if the cycle limit is exceeded. Then when calculating the stack upper bound, we multiply the cycle stack size by the recursion limit. So you then would decide at compile time how much stack space you're going to ask for from the OS. The benefit of this idea is that it actually does not depend on any changes to LLVM and we could implement it even before #157 is finished. Until #105 is done we would have to specify the Recursive or LimitedRecursive calling convention on the first node getting called in the cycle (B in the picture).

github.com/ziglang/zig

Builtin function to tell you the maximum stack size of a given function

opened 03:47PM - 10 Jul 16 UTC

andrewrk

proposal accepted frontend

I propose a `@stack_size(function)` builtin which returns the number of bytes th…at `function` - which must be a compile time constant function - will ever possibly use for the deepest call invocation. This function causes it to become a compile error if the function named - or any function called therein, invokes direct or indirect recursion on a non-compile time constant parameter. ~Similarly, if any function causes a runtime stack allocation to occur, such as `var foo: [x]u8 = undefined;`, where `x` is a parameter to the function invoked with a non compile time constant.~ This feature has been removed from zig This builtin function could be used when creating a new thread, to determine the stack size. This stack would never have to grow or shrink, and it would be the maximum number of bytes that could possibly be used, likely very small. It would also force the programmer to not use recursion on user input, a limitation that some categories of software require, and violating this would be caught by the compiler, since it makes returning a correct number from `@stack_size()` impossible. Users may even want to introduce this limitation on the main thread, and they could do this by adding a top level assert such as `comptime { assert(@stack_size(main) <= 16 * 1024 * 1024); }` or some such. If they do this, then we can modify the binary's stack size to be only as large as necessary, which is probably a minuscule improvement in memory footprint and startup time, but it's a strong guarantee of robustness at least in this one regard. Another thing that would cause this function to cause a compile error is calls to an external library. External library functions could be annotated with a maximum stack size attribute, or we can have another threading abstraction that does not use `@stack_size()` for when we don't know the upper bound of how big a stack will grow. Tangential idea: when Zig outputs a shared library, in the .h file it generates, it can annotate functions with additional information in the comments, such as maximum stack size, and Zig can look for these annotations when importing .h files. This function also introduces some weird interdependencies. For example, I could do: ``` zig fn a() { var bytes: [@stack_size(b)] = undefined; } fn b() { a(); } ``` Zig would have to detect this dependency loop and report a compile error. Implementation of this would be a bit tricky since currently it is LLVM that determines the stack size of everything, and optimizations can increase and decrease the stack size of various functions. However, I think it is possible to have a sound upper bound. @thejoshwolfe thoughts?

Some other related proposals to provide context as to why unbounded stack growth isn’t likely to be something the language ever implements.

github.com/ziglang/zig

Proposal: stackless coroutines as low-level primitives

opened 12:09AM - 03 Apr 25 UTC

mlugg

proposal

This proposal assumes the existence of #23367. ## Background At the time of wr…iting, @andrewrk and @jacobly0 are [exploring the idea](https://github.com/ziglang/zig/tree/async-await-demo) of implementing async/await in userland, based on the new `Io` interface. This allows using different approaches to implement async, such as single-threaded blocking, thread pool blocking, or green threads / fibers. The latter approach is likely to become the preferred method, because it is fairly performant and conceptually simple. At this point it seems incredibly likely that this will become the path forward for async/await in Zig; it has a lot of advantages! However, stackful coroutines via green threads do have some flaws. One of the most significant is that they simply aren't supported on some targets, such as Wasm and SPIR-V. Wasm is a particularly interesting example, because using stackless async in Wasm can be desirable in order to integrate with the JavaScript event loop -- for instance, expensive work in Wasm ought to periodically yield to the browser to allow other work to happen. The only way we can really do that is through stackless coroutines, which require language-level support. **In general, stackless coroutines will have broader support than stackful coroutines, because all of the suspend/resume machinery is lowered by the compiler to synchronous constructs.** #6025 proposes re-introducing stackless coroutines, as in stage1, to the self-hosted compiler. **This proposal competes with #6025** by taking the alternative approach to provide simpler primitives upon which a stackless `std.Io` implementation can be built, forgoing nice syntax and type safety in favour of a simpler language specification and compiler implementation. This proposal assumes that language features pertaining to "old" async (e.g. the `async`, `await`, and `anyframe` keywords) are removed. ## Proposal Add the following declaration to `std.builtin`: ```zig pub const AsyncFrame = opaque {}; ``` Implement the following builtins: ```zig /// Returns the required size of the async frame buffer for the given function or function pointer. /// Function pointers must be restricted (#23367). /// The result is always comptime-known. @asyncFrameSize(func: anytype) usize; /// Initializes an async frame in `frame_buf`, such that calling `@asyncResume` on the /// returned frame pointer will begin executing the function. /// `func` may be a function or function pointer. /// Asserts that `frame_buf.len` matches `@asyncFrameSize(func)`. /// The parameter to `func` is given at the call to `@asyncResume`. /// "Frame buffer" and "frame pointer" mean different things. The returned frame pointer /// is somewhere within `frame_buf`, but its exact address is arbitrary. @asyncInit(frame_buf: []u8, func: *const fn (*anyopaque) void) *std.builtin.AsyncFrame; /// Given a function's frame pointer, resumes that function. /// Despite the name, this is also how you first start running an async function after calling `@asyncInit`. /// If this is the first time resuming (i.e. this frame was just initialized), `arg` is passed to the `func` /// given in `@asyncInit`. Otherwise, `arg` is returned by the `@asyncSuspend` we are resuming from. /// Returns the argument to the `@asyncSuspend` call, or `null` if the function completed without suspending. /// If the call completed, it is Safety-Checked Illegal Behavior to call `@asyncResume` on this frame again. @asyncResume(frame: *std.builtin.AsyncFrame, arg: *anyopaque) ?*anyopaque; /// Suspends the current function. All live values are spilled to its async frame buffer if necessary. /// After the function is suspended, control flow returns to the nearest `@asyncResume` site. /// The `data` argument is returned from `@asyncResume`. @asyncSuspend(data: *anyopaque) *anyopaque; /// Retrieve the current function's async frame pointer. /// If this is not an async function (i.e. it has no suspension points), `null` is returned. @asyncFrame() ?*std.builtin.AsyncFrame; // EDIT: this last builtin is unnecessary! Disregard it... // /// Like `@call` with `std.builtin.CallModifier.auto`, but asserts that the call never suspends, even // /// if it is an async function. In other words, the callee having suspension points does not give the // /// caller a suspension point. If the callee suspends, Safety-Checked Illegal Behavior is invoked. // @asyncNoSuspendCall(func: anytype, args: anytype) anytype ``` All relevant builtins begin `@async`, making the scope of this language feature very clear. Mapping concepts from #6025 to this proposal: * `@Frame()` and `anyframe` types do not exist; raw byte buffers and opaque pointers are used. * `@frame()` is called `@asyncFrame()`. * `async foo()` is equivalent to `@asyncInit` followed by `@asyncResume`. * `await frame` is equivalent to repeated `@asyncResume` calls until one returns `null`. * ~~`nosuspend foo(arg)` is equivalent to `@asyncNoSuspendCall(foo, .{arg})`.~~ * Actually, `nosuspend foo(arg)` is just `@asyncInit` followed by `@asyncResume` but asserting that the latter returns `null`! * `suspend` is `@asyncSuspend()`. There is no longer a "suspend block"; I elaborate on this below. * `resume` is `@asyncResume()`. I elaborate on the argument and return value of this builtin below. A function is async if it has any "suspension point". A suspension point is: * a usage of `@asyncSuspend`, or * a call of another async function (including through `@call`) An async function must have `callconv(.auto)`. ## Suspending and Resuming Under #6025, when a function suspends, control flow moves to its "suspend block" before being passed to the `resume` or `async` site. This block is generally responsible for actually queuing the asynchronous operation, and storing the `@frame()` somewhere ready to be resumed when the operation completes. The crucial thing is that once in the `suspend { ... }` block, the function is already considered suspended, so it is safe for another thread to resume it. This proposal takes a different approach for simplicitly. The `@asyncSuspend` builtin takes a value of type `*anyopaque`, which is returned by the corresponding `@asyncResume()` call. That `@asyncResume()` call can then use that arbitrary data to queue the operation and store the async frame somewhere. The code which calls `@asyncSuspend` would include in that pointer the current `@asyncFrame()`, so that the event loop knows which frame pointer to resume later, and information about the reason for suspension, so that the event loop can schedule the appropriate action. Later, when the function is resumed, an argument (again of type `*anyopaque`) is passed to `@asyncResume`, and this value is returned from the `@asyncSuspend` we are resuming from to act as a kind of "result". This approach wasn't possible under the old design, because writing `var frame = async foo();` needed to queue the asynchronous operation without requiring the user to put extra code after that `async` invocation. However, the equivalent for this code is now `var future = io.async(foo, .{});`, so the `async` implementation is free to implement this machinery. ## Implementation Notes The implementation still internally has the concept of "awaiters", due to function calls. When a function directly calls another async function, the caller creates a frame buffer nested in its own frame, initializes it, marks itself as the "awaiter" inside that frame, and *then* calls the callee. However, this internal "awaiter" field would only be for direct function calls; it wouldn't apply to `io.await`, which would be implemented in the event loop by (very vaguely, ignoring parallelism/atomic issues): * Storing, in the event loop, that the awaiter is waiting for the awaitee * `@asyncSuspend()`ing the awaiter * Allowing the event loop to repeatedly resume the awaitee until it finishes * Once the awaitee finishes, resuming the awaiter again, based on the event loop's own state I'm not sure if this point is novel (I wasn't deeply familiar with the legacy async implementation), but: this call (one async function directly calling another) can actually be a tail call, because the callee will then tail call the caller again once it returns (due to the caller being marked as its "awaiter" in this internal field). This decreases stack usage, and also speeds up suspension, because there's no need to unwind the whole stack. One nice thing about `async` and `await` being implemented in userland is that the `@async` builtins do not need to be aware of threads. In the legacy async implementation, each frame included one or two atomic fields to deal with an `await` racing with frame completion. In contrast, this proposal offloads that work into the `Io` implementation, which can choose how to handle it. This could be a performance advantage; LLVM struggles to optimize around those atomics, so a stackless-coroutine-based event loop which knows it's single threaded (even if the application as a whole is not `-fsingle-threaded`) could choose not to use an atomic flag, helping the optimizer. ## Closing Notes There are details of this proposal that need to be hashed out; coroutines are complicated! There are also probably things I need to specify which I haven't (like clarifying how this interacts with function pointers). Nonetheless, I wanted to put this proposal up to invite discussion on this potential path forward which I, for one, am quite excited by.

github.com/ziglang/zig

Proposal: restricted function types

opened 02:05PM - 26 Mar 25 UTC

jacobly0

enhancement optimization proposal accepted

## Preamble Indirect calls through function pointers are a major blocker for bo…th #1006 and #6025. While a solution can be designed for the generic case, there always seems to be *some* core function pointer usage, often related to interfaces, that the breaks the generic solution. This proposal is intended to provide a way to represent some common usages of function pointers, particularly in interfaces, in a way that is both more optimizable and decoupled from various difficult design problems.. ## Motivating Example Let's consider some simple interface for demonstration purposes: ```zig pub const Operation = struct { vtable: *const VTable, pub const VTable = struct { operate: *const fn (x: i32) i32, }; pub fn operate(op: Operation, x: i32) i32 { return op.vtable.operate(x); } }; pub const addOne: Operation = .{ .vtable = &.{ .operate = &addOneOperate, } }; fn addOneOperate(x: i32) i32 { return x + 1; } pub const double: Operation = .{ .vtable = &.{ .operate = &doubleOperate, } }; fn doubleOperate(x: i32) i32 { return x * 2; } fn negate(x: i32) i32 { return -x; } fn testOperation(name: []const u8, op: Operation) void { for ([_]i32{ 1, 7, 12 }) |x| std.debug.print("{s}({d}) = {d}\n", .{ name, x, op.operate(x) }); } const std = @import("std"); pub fn main() void { testOperation("addOne", addOne); testOperation("double", double); var negate_op: Operation = undefined; negate_op.vtable = &.{ .operate = &negate, }; testOperation("negate", negate_op); } ``` ``` $ zig run example.zig addOne(1) = 2 addOne(7) = 8 addOne(12) = 13 double(1) = 2 double(7) = 14 double(12) = 24 negate(1) = -1 negate(7) = -7 negate(12) = -12 ``` When the optimizer sees the indirect call `op.vtable.operate(x)`, it would be nice if it could know that all of the possible callees are pure, or other useful properties that hold for all callees. This would be easily determinable by iterating all of the callees, but that requires knowing all of the callees in the first place. In a more complicated example, it would be easy for an `Operation` to come from somewhere where the optimizer is not sure which vtable it holds, and then it is forced to assume that `op.vtable.operate(x);` could mutate any and all global state. ## Proposal In pursuit of these goals, I propose having a language syntax that allows the compiler to be able to collect a complete list of all possible callees and communicate these to the optimizer at each call site. Here's a tentative syntax proposal, I'm sure it could be improved, but this is just to demonstrate the idea: ```diff pub const Operation = struct { vtable: *const VTable, pub const VTable = struct { - operate: *const fn (x: i32) i32, + operate: *const Operate, + + pub const Operate = @RestrictCallees(fn (x: i32) i32); }; pub fn operate(op: Operation, x: i32) i32 { - return op.vtable.operate(x); + return op.vtable.operate(x); // This may only call `addOneOperate`, `doubleOperate`, or `negate` } }; pub const addOne: Operation = .{ .vtable = &.{ - .operate = &addOneOperate, + .operate = &@allowCallee(addOneOperate), } }; fn addOneOperate(x: i32) i32 { return x + 1; } pub const double: Operation = .{ .vtable = &.{ - .operate = &doubleOperate, + .operate = &@allowCallee(doubleOperate), } }; fn doubleOperate(x: i32) i32 { return x * 2; } fn negate(x: i32) i32 { return -x; } fn testOperation(name: []const u8, op: Operation) void { for ([_]i32{ 1, 7, 12 }) |x| std.debug.print("{s}({d}) = {d}\n", .{ name, x, op.operate(x) }); } const std = @import("std"); pub fn main() void { testOperation("addOne", addOne); testOperation("double", double); var negate_op: Operation = undefined; negate_op.vtable = &.{ - .operate = &negate, + .operate = &@allowCallee(negate), }; testOperation("negate", negate_op); } ``` The way this works, is that some syntax like `@RestrictCallees` creates a function type that does not compare equal to other function types with the same signature. Instead, this produces a unique type in the same way as container type definitions, where a combination of the source location and captured values determines equality. Syntax like `@allowCallee` casts a comptime-known function value into the result restricted function type, checking that the signatures are compatible and adding a callee to the set of possible callees for that restricted function type when analyzed. It would be checked illegal behavior to make an indirect call through a pointer to a restricted function type when the value of that pointer is not in the set of possible callees that were analyzed during compilation. Additionally, restricted function types would be required to be `callconv(.auto)`, because this feature is not designed to handle function pointers passed to and from external code, and to facilitate the aforementioned safety checks. As an example implementation in the llvm backend, a metadata node forward reference could be reserved the first time an indirect call to a given restricted function type is encountered, and attached to every indirect call through that restricted function type. Then, during flush, these could be iterated and each metadata node filled in with all of the callees collected by the frontend. ## ~~Open~~ Questions * ~~Does this prevent an interface such as `std.mem.Allocator` from being passed to another zig compilation unit? I believe this wouldn't work in the future anyway, because non-extern struct types would not be compatible between different ZCUs, due to the not-yet-implemented type tags not matching.~~ *This is indeed already illegal behavior.* * ~~How does this interact with incremental? Incrementally adding callees seems simple enough, but can we incrementally remove a callee when all instances of `@allowCallee` for a given function become no longer referenced? Just leaving it in the callee set wouldn't work since that would cause a false negative a safety check.~~ *Using restricted function pointers that are distinct from the original function pointer makes this a non-issue.* * ~~Is it useful to introduce a "restricted function pointer cast" that casts a runtime known normal function pointer into a compatible restricted function pointer and safety checks that the runtime function pointer is one of the analyzed allowed callees? Depending on how the indirect call safety check is implemented, this could be trivial or difficult.~~ *Not considered useful at this time.*

vulpesx · February 5, 2026, 9:34am

Pls try to keep discussion civil, we are all engaging in good faith, if we weren’t then we’d be wasting our own time.

Some information you are certainly missing is that local variable lifetimes are supposed to be scope based, not function based. Currently, the compiler does function based lifetimes, but that is just a bug and will be fixed eventually.

Your proposal requires function based lifetimes, which requires that you change the opinion of Andrew, good luck it’s not easy.

your example suggests that it works within loops

how does this work if the loop bounds are runtime known? Defers are inserted statically before each return/break/end of scope. If you want it to work with runtime loops then that would be a BIG change in how the compiler works.

How does this work with local variables in loops? Currently, they are overwritten each iteration.

I see you answered those by limiting to comptime known bounds and not referencing in-loop variables. With those restrictions it should be possible and potentialy easier to generate a defer for

Lastly, how does it work when returning inside the loop/nested loop? It would need to dynamically adjust to how many iterations there have been, which may be difficult to implement.

regarding your arguments, not the idea itself

In the context of the previous paragraph I can see how it looks that way. But it is inaccurate, errdefer is still scope based, it just limits where it is triggered to returning an error. errdefer is a special case of defer.
Your redefer is more of an alternative to defer, but can be implemented using defer in the compiler making it a special case of defer.

This is somewhat subjective, @marler8997 demonstrated that it is trivial for your example.

While redefer may help with this, I would argue that it is an issue with the programmers design.

Reusing your 2d array example, you can remove a layer of allocation with some simple maths:

// you would want to make a type to handle this safely
const width = 2;
const height = 2;
var a = try allocator.alloc(f64, width * height);
// might not be neccessary, if no errors could be returned after this
// you can assert that with `errdefer comptime unreachable`
errdefer allocator.free(a);

// pretend this is a fn get(x,y)
const x = 0;
const y = 2;
// row major: [ row0[0, 1], row1[0, 1] ]
a.items[y * width + x];
// collumn major: [ collumn0[0, 1], collumn1[0, 1] ]
a.items[x * height + y];

I agree with this! But in my subjective experience cases complex enough to warrant a something like redefer are not common.

in response to: Proposal: A New redefer Keyword for Function-Scoped Deferred Execution - #3 by marler8997

You can’t just make statements like this without explaining them, it may be obvious to you, but it isn’t to everyone else.

What implicit conditions does it rely on? What changes make it ineffective?

Keeping code concise and not liking length code are very subjective preferences, why should zig cater to your preferences?

A better argument: currently, there can be a detachment from the defer and the code It’s related to, this hampers readability and may result in forgetting to update either of them. This is the same logic that justifies defer and errdefer.

some relevant thoughts that didn’t fit with any of the above sections

I don’t think redefer is clear enough to be the keyword.

It isn’t clear if it runs in the parent scope or in the root scope of the function?

If the latter than fndefer would be a good keyword.

If the former than perhaps defer :label with a labelled scope?
Should this allow going multiple scopes out, or be restricted to only 1 or some other limit.
Would the label be the scope it runs in, or the scope it escapes?
The former would require special case to run in the root fn scope, so the latter may be preferable.

Should there be an err variant? It’s possible that makes more sense than a non err variant?

Joen-UnLogick · February 7, 2026, 12:03pm

Rant incoming! Seriously this is messed up.

That’s a serious footgun to leave open! I’ve seen loops allocating and added to a list with defer free and the value being used outside the loop. If this works due to a bug it’s a massive footgun! I’m pretty sure I’ve seen this pattern and copied it into my code somewhere. I probably read that defer is scope based, but let’s not pretend the sparse docs to be gospel in one area and completely missing in another. When the debug allocator with it’s zeroing of freed memory confirms the loop is good it teaches my brain that this is a valid pattern.

The fix would be to loop the list in the function scoped defer and free the elements before the list but suddenly I have to do bookkeeping since not all of my allocations are of the same size. On top the flow becomes wieldy and hard to read.

Having a key feature like defer being implemented incorrectly for years, that’s troubling. Just saying!

Edit: As others have pointed out my use case would be better suited for a temporary arena, that reduces the cleanup substantially by only dealing with blocks instead of allocations. Rant still stands on having a crucial keyword such as defer having such a critical glaring bug though.

IntegratedQuantum · February 7, 2026, 1:13pm

I think such a keyword is not justified. The fundamental problem is that this is not a particularly good way to handle local allocations. Managing memory like this, with many small allocations, is going to cause performance problems and, as you discovered, also safety problems.

There are several better ways to handle memory, that may also end up leading to more readable code. The most common one is using an arena:

// It requires some setup, but this can also be moved up in scope, e.g. a game may just have one arena for the entire frame
var arenaAllocator = std.heap.ArenaAllocator.init(allocator);
defer arenaAllocator.deinit();
const arena = arenaAllocator.allocator();

// But the rest of the code becomes almost trivial, no more bookkeeeping
const a = try arena.alloc([]f64, 2);
for(0..2) |i| {
    a[i] = try arena.alloc(f64, 2);
}

Other options may be programming without pointers (using an ArrayList(f64) and storing indices into it instead of slices), preallocating the memory, or using an allocator that cannot fail.

I’d question the need to modify the data in the first place. It seems like a rather niche action, and I don’t see an advantage beyond just using regular defer if the functions is simple or storing an ArrayList of modifications if it’s more complex.

At the end of the day if you really need it, you can also just implement the redefer functionality in user space using an ArrayList and regular defer.