std.math.isInf either should support ComptimeFloat or should have a clearer error message

[ssteinbach]

Zig Version

0.14.0-dev.2340+182cdf74b

Steps to Reproduce and Observed Behavior

test {
    _ = std.math.isInf(3.0);
}

Produces error:

~/zig/0.14.0-dev.2340+182cdf74b/files/lib/std/math/isinf.zig:8:55: error: access of union field 'float' while field 'comptime_float' is active
    const TBits = std.meta.Int(.unsigned, @typeInfo(T).float.bits);
                                          ~~~~~~~~~~~~^~~~~~
~/zig/0.14.0-dev.2340+182cdf74b/files/lib/std/builtin.zig:556:18: note: union declared here
pub const Type = union(enum) {
                 ^~~~~
/var/tmp/inftest.zig:21:23: note: called from here
    _ = std.math.isInf(3.0);
        ~~~~~~~~~~~~~~^~~~~

std.math.isFinite produces the same error.

This error is present in zig 0.13.0 as well.

Expected Behavior

Given that std.math.isNan supports ComptimeFloat arguments, I expected std.math.isInf / std.math.isFinite to also support them. If there is a reason why it shouldn't support ComptimeFloat, then a more helpful @compileError() might be helpful. Just flagging this in case it was missed! Thanks all!

[rootbeer]

I think #21198 and #21205 are relevant here. If I'm reading those correctly, Zig won't support inf/nan in comptime floats (any operations that would generate them at compile time would instead generate a compile error). I believe this work is in progress (see #23177 which went in yesterday).

For now, the work-around seems to be a cast: std.math.isInf(@as(f128, 3.0))

[mlugg]

In light of #21205, it makes sense for isInf to not support comptime_float, in just the same way that it does not support integers/comptime_int because while, yes, integer values aren't infinity, the query just doesn't really make sense to begin with on those types. #21205 makes comptime_float more akin to a "real number" type (albeit with precision around the same as an IEEE-754 binary128 floating-point value).

In terms of the compile error, we typically avoid introducing custom @compileError logic to std in cases like this. As such, I think there is no further work to do here, and will close this issue.