Add ability to determine if we are currently executing at compile time

[tiehuis]

I'm sure this was mentioned somewhere but could not find an issue: The gist is as follows:

if (@areWeInComptime()) {
   // use a slow fallback which we can compute in zig
} else {
   // use a fast runtime version that uses assembly (or features not supported at comptime)
}

This is present in D for example via the __ctfe variable. The current reason I need this is that I want to call sqrt at compile-time but on x86_64 this uses an assembly routine which can not be evaluated at compile-time.

[andrewrk]

I think this makes sense. One thing I want to avoid though is over-reliance on this. In most cases we should strive to make the runtime and comptime representation the same. Something that I never want to see is a function that could have been perfectly fine executing in both comptime and runtime contexts, but somebody didn't think that was possible and did something like if (@areWeInComptime()) @compileError("unsupported").

In the case of inline assembly for sqrt, see #767

[tiehuis]

Completely agree on not over-relying on this. I did forget about the llvm math intrinsics. I'm happy enough to hold of on this for now until we get other possible use cases that require something of this sort.

[andrewrk]

It's kind of a dirty secret that this is possible, but...

const std = @import("std");

test "detect comptime" {
    std.debug.warn("\n");
    std.debug.warn("1={}\n", isCompTime());
    std.debug.warn("2={}\n", comptime isCompTime());
    std.debug.warn("3={}\n", comptime isCompTime());
    std.debug.warn("4={}\n", isCompTime());
}

fn isCompTime() bool {
    var t: bool = true;
    const x = if (t) u7(0) else u8(0);
    return @typeOf(x) == u7;
}

Don't rely on this - zig reserves the right to make the if static if it can prove the value is compile-time known (which it should be able to do in this example with more sophisticated semantic analysis).

[jibal]

Don't rely on this - zig reserves the right to make the if static if it can prove the value is compile-time known (which it should be able to do in this example with more sophisticated semantic analysis).

Having to rely on it is even worse than the possibility of abusing @areWeInComptime().
(And now it doesn't work but there's no apparent workaround. I think that it would have been a really good idea to add @areWeInComptime to the language when this stopped working.)

In most cases we should strive to make the runtime and comptime representation the same.

Sure, but there are things that are ok at comptime but produce errors or even crashes at runtime and v.v. (consider the existence of comptimePrint), and one needs to detect them in order to write complex generic code (which I'm in the process of doing and finding a number of roadblocks, like the lack of implementation of #425, which is forcing extreme awkwardness in my API; I have dozens of functions that always operate at comptime and they all have to be explicitly qualified with comptime at the call site and every one is a potential bug ... so I have changed them to return a type (a struct with a const containing the actual value) or comptime_int rather than bool (mostly) ... why can't we simply declare a function to return comptime bool?

Another example, pointed out in #5672, is the error message "error: variable of type 'T' must be const or comptime". The existence of such errors makes it necessary to be able to detect whether they will occur in generic functions. Personally I would prefer if there were no such errors ... if the type makes the variable comptime then the compiler should just make it comptime. Write enough generic code and you'll see why this should be the case. And if that requires a while or for to be inline, then the compiler should just make it so. Otherwise you have to write two (or more) versions of generic functions, one for comptime arguments and one for runtime arguments. Either do this always or allow an explicit declaration saying that this is generic code that should work in either case.

Edit: example: functions like std.mem.copy don't work on a slice of comptime_int or other comptime types. ("error: values of type 'comptime_int' must be comptime known, but index value is runtime known")

There's tension/conflict between generic functions and Zig's principle of being explicit. Generic functions may operate very differently and produce code with very different characteristics depending on the types of its arguments. Requiring explicit comptime and inline qualifiers rather than inferring them may be fine for forcing end-users to know what's going on, but this approach doesn't apply or work correctly for generic functions,

[topolarity]

There's another dirty trick possible with stage2's inline semantics:

inline fn isComptime(val: anytype) bool {
    return @typeInfo(@TypeOf(.{ val })).Struct.fields[0].is_comptime;
}

test {
    const a: i32 = 15;
    @compileLog(isComptime(a)); // true
    
    var x: u64 = 15;
    @compileLog(isComptime(x)); // false
    @compileLog(isComptime(x >= 0)); // true
}

Compared to the code above, this one seems guaranteed to work as expected even as semantic analysis improves.

If we don't want this to work, that probably requires a solution to #12261