Understanding comptime

[n0s4]

@uben

Also, for reference counting, it is also an intuition, as from my experience, any value can escape its defining scope, there won’t be an undefined behavior. I just don’t see any other mechanism than reference counting that can do so (and garbage collection). Even an arena allocator has a scope.

I found the post I read that from, the whole thing is worth reading: Comptime Garbage Collection - #3 by mlugg.

Particularly

@mlugg

Sema is no exception – each instance of Sema stores an arena: std.mem.Allocator field. This arena is used for any temporary data needed during semantic analysis – such allocations are thrown into the arena, which is then chucked out when this individual semantic analysis completes. A single analysis is either analyzing the value of a declaration (a global const or var), or is analyzing a runtime function body (type checking it and generating code). Any such analysis may call arbitrary comptime code: for instance, in your snippet, analysis of the runtime body of main evaluates getEvens(16) at comptime.

Ah, but of course I misread it. This is talking about temporary state the compiler has when processing these comptime values. The values themselves are stored in an InternPool, which in theory would be garbage collected:

@mlugg

Regarding interned values (those stored in the InternPool), the idea is that the pool can undergo periodic garbage collection using a simple conventional mark+sweep approach. However, this is currently vaporware, since the InternPool is a fairly new creation (more on this later). Thus, interned values are currently never cleaned up.