ability to mark functions as wanting to be comptime if possible

[andrewrk]

Use case: if the parameter to assert is comptime known, we for sure want to execute the assert function call at compile-time. It would catch a lot of bugs at compile-time instead of generating, essentially assert(false) in some places.

So here's a proposal to have a way to mark a function as "eager to be comptime", which means that if all parameters are comptime known, the compiler executes the function and uses the result instead of emitting a runtime function call.

We can't have all functions do this, because functions can contain runtime side effects even if all params are comptime known, and we do want to have compile errors for hitting runtime side effects at compile time for these kind of functions. Case in point, we want the if (!ok) unreachable to be a compile-error in the assert function if ok is false. So this is why the user has to mark a function as "eager to be run at compile time".

Here's one syntax proposal:

comptime fn assert(ok: bool) {
 if (!ok) unreachable;
}

The thing I don't like about this is it looks like assert always has to be run at compile-time, but it doesn't. It also looks like you have to mark a function comptime before you can use it at compile-time, and that's also not true.

[raulgrell]

I was going to propose something along these lines, where you could mark a function as either optionally comptime or must be comptime. I also didn't know which syntax would be best for these scenarios. Something like:

Eager comptime:

comptime fn assert(ok: bool) {
 if (!ok) unreachable;
}

and enforced comptime

fn comptime_assert(ok: bool) -> comptime void {
 if (!ok) unreachable;
}

[thejoshwolfe]

For assert, what about just marking it inline? Then the caller will get if (comptime something) unreachable which becomes if (false) unreachable which becomes unreachable, which is a compile error.

[andrewrk]

export fn foo() {
 unreachable;
}

compiles fine currently. Should this be a compile error? "control flow guaranteed to hit unreachable code"

if so then I really like the idea that marking assert inline would have this behavior. That would also require implementing inlining in Zig (frontend) rather than using the LLVM always_inline attribute (backend).

which maybe we want, because sometimes LLVM doesn't inline even when we put always_inline attribute on. I made this an error, but it's kind of like a hopeless, welp, it didn't work, nothing zig can do about it, kind of error.

[thejoshwolfe]

"control flow guaranteed to hit unreachable code" sounds like the halting problem. What about a function that unconditionally hits unreachable but that's called conditionally?

I think inline is a red herring. Let's go back to the original proposal.

Can you give an example of code that shows this issue? i can imagine cases where we do want to generate assert(false), for example:

switch (event.type) {
 EventType.PosixSignal => {
 assert(!is_windows);
 foo(event);
 }
}

[scallyw4g]

I sat in on a live stream @andrewrk did last week and had some thoughts about this.

IIRC the state of comptime at this time (or at least at the time of the stream) is that a block or function at the call site can be marked as comptime. This is good and I like that it's 100% explicit, however it may become overly verbose in the case of something like assert.

Continuing down this line of thinking, we'd like to be able to mark functions as being run at compile time - a reasonable ask.

I believe that there's an argument to be made for having a pair of keywords for this. One keyword says "Mr zig compiler, please only ever run this function at compile time", while the other keyword says "Run this at compile time if possible, but also generate a runtime counterpart".

With the assert example in mind we would end up with two functions, assert and comptime_assert, which work in their respective "time scopes?" - assert is a regular function and comptime_assert is only ever evaluated at compile time.

The reason I propose this is a bug I thought about that it guards against. Imagine we're doing compile time string hashing. If our string hash function accidentally gets passed a runtime string in a place we're expecting it to be passed a const string we're going to have a performance bug. Similarly, if a single assert function worked both at runtime and compile time, there's a chance we would accidentally pass it a runtime value, compile fine, then be oblivious to the fact we may have a bug in that path.

I particularly think the assert case is a compelling reason to have at least a way of saying "only ever run this at compile time", but it would be convenient to have both to sometimes avoid code duplication.

Not sure if this is a useful idea, or already solved in some other way, but I thought it would be worthwhile sharing.

Cheers,
Jesse