No dynamic memory allocation at comptime

Goes hand in hand with #5718. I hate hate HATE the current comptime memory management strategy. It flies in the face of everything Zig stands for. It breaks rules just for the sake of it. It requires fundamentally different logic at comptime vs runtime. It's ill-suited for applications that do heavy computations at comptime (regex, interfaces, perfect hashing etc.). #5873 proposes a better solution, and this proposal makes another thing explicit: a pointer should not be able to manage the memory it points to. So code like this should not be allowed. It requires complex logic in the compiler to detect lifetimes (a motherfreaking GARBAGE COLLECTOR for Kristoff's sake), as well as built-in reallocation logic. We invented better ways to do these things, let's not rely on unreliable solutions. Let's use the same programmer's model at comptime that we do at runtime, and only break it when we have to, not just for the sake of it.

[andrewrk]

Can you give an example of something that this proposal would disallow, that is not already covered by other proposals / bug reports?

There's one linked in the OP. err_handlers is a slice, but also the source and primary handle of the memory it points to. The linked line does not resize err_handlers, but it does resize the memory pointed to by it, which could require an implicit relocation -- even though, from looking at the code, no heap allocation was attempted. This is a fundamentally different operating principle than runtime code, and violates the "one language" principle we've worked to achieve in other areas. This proposal would disallow it. I haven't seen this issue covered elsewhere.

[andrewrk]

Here's an even simpler example of dynamic memory allocation at comptime:

fn initArray(comptime len: usize) [len]u8 {
    var array: [len]u8 = undefined;
    for (array) |*elem, i| {
        elem.* = i * 10;
    }
    return array;
}

var array = initArray(100);

This, along with the linked code, is planned to be part of the language specification.

Note that garbage collection at compile time is quite normal, and already happens at the link stage of all ahead-of-time compilers, when it finds out what code/data can be omitted from the final binary. (This is what the linker flag --gc-sections does.) Many optimization passes of compilers could be modeled as garbage collectors.

That's not quite the same thing. The data in that case is managed directly, rather than through a pointer, and not resized once it's created. That's consistent with runtime semantics.

Regarding GC within the compiler, ok, sure, but we shouldn't expose that directly to userspace comptime code. That locks users in to one memory management strategy, which is not well suited to all cases, as well as encouraging a style for comptime code which is invalid for runtime code.