ziglang
math.pow: add f16, f80, f128, c_longdouble, comptime_float support
Removes the compile error restricting math.pow to f32/f64, allowing its use with f16, f80, f128, c_longdouble and comptime_float.
~Adds a compile error when T is comptime_float. The current pow implementation relies on concrete float properties (e.g., bit layout via @typeInfo(T).float.bits) which aren't available for comptime_float as far as I can tell.~
~There may be other ways to handle this, but this approach at least adds support for the concrete floating point types :)~
comptime_float behavior tries to follow that described in: https://github.com/ziglang/zig/issues/21205#issuecomment-2613393221
Fixes: #23602
Adds a compile error when T is comptime_float. The current pow implementation relies on concrete float properties (e.g., bit layout via
@typeInfo(T).float.bits) which aren't available forcomptime_floatas far as I can tell.
I believe the current thinking is that comptime_float should mostly behave as f128, except for NaNs, or something like that. @mlugg can you confirm?
It seems that comptime_float should behave like f128 but where NaN and inf result in compile errors. With that in mind, it seems like, when comptime_floats are passed in, you could just cast them to f128s, and if the result is NaN or inf, throw a @compileError(). Are there any problems with that approach that I'm missing?
Casting comptime_float inputs to f128 and then checking the result seems like the plan.
It seems that comptime_float should behave like f128 but where NaN and inf result in compile errors.
@Empika1 - Can you point to where you see this pattern? I wasn't able to find anything similar myself.
Still wondering if we should @compileError on both NaN and Inf results from the f128 cast, or only NaN?
If it's only NaN, perhaps the existing NaN handling within pow is sufficient, and we'd just need the conditional cast to f128?
@alexrp / @mlugg, could you clarify the intended behavior?