Can't call inline function that returns comptime-known comptime-only type at runtime

[castholm]

Zig Version

0.12.0-dev.2711+f995c1b08

Steps to Reproduce and Observed Behavior

Extracted from #18808 (comment)

However... when I tried this example below I was actually surprised:

const std = @import("std");

extern fn side_effect(*i32) void;

inline fn example(runtime_known: *i32, comptime x: bool) type {
 if (x) {
 return f32;
 } else {
 side_effect(runtime_known);
 }
}

test "pass runtime param, receive comptime value" {
 const ptr = try std.testing.allocator.create(i32);
 defer std.testing.allocator.destroy(ptr);

 const T = example(ptr, true);
 try std.testing.expect(T == f32);
}

test.zig:17:23: error: unable to resolve comptime value
 const T = example(ptr, true);
 ^~~
test.zig:17:23: note: argument to function being called at comptime must be comptime-known
test.zig:5:58: note: expression is evaluated at comptime because the function returns a comptime-only type 'type'
inline fn example(runtime_known: *i32, comptime x: bool) type {
 ^~~~
test.zig:5:58: note: types are not available at runtime
inline fn example(runtime_known: *i32, comptime x: bool) type {
 ^~~~

The problem here is that the return type forces the function call to be comptime, when we actually just wanted it to be inline. I will open a bug report for this.

I couldn't find a bug report.

Another quick test that should succeed:

const std = @import("std");

test "inline function with comptime-known comptime-only return type called at runtime" {
 const S = struct {
 inline fn foo(x: *i32, y: *const i32) type {
 x.* = y.*;
 return f32;
 }
 };
 var a: i32 = 0;
 const b: i32 = 111;
 const T = S.foo(&a, &b);
 try std.testing.expectEqual(111, a);
 try std.testing.expectEqual(f32, T);
}

Expected Behavior

All tests pass.

[nektro]

both code snippets would only make sense to pass if inline functions were macros; which they explicitly are not

[RossComputerGuy]

This doesn't feel like a bug, you can't have a function return a type at runtime. However, you can set it up so the return value changes based on the parameters. But I am pretty sure if you return type then all arguments have to be comptime.

[castholm]

Please read the linked comment. inline already propagates the comptime-known-ness of inputs and output, this is nothing new. We are not returning a type at runtime here, the type is 100% known from the comptime-known arguments.

The bug is that the comptime-only return type is incorrectly "upgrading" the call from an inline call to a comptime call, which it shouldn't.

[nektro]

which it shouldn't

i saw the original comment when it was posted and i still wholeheartedly disagree. it's still a call, it being inline just means the comptime-knownness of the return type/value is inherited at the callsite

[SpexGuy]

Just wanted to chime in in defense of this issue. I agree with the OP that this is a bug. Inline functions are not macros exactly, but they are very similar to hygienic macros. Inline functions can do both of:

• have runtime side effects, and
• return a comptime known value.

So there's also nothing wrong with an inline function that

• has runtime side effects, and
• returns a comptime known value of a comptime only type.

The bug here is due to promoting functions that return comptime-only types to execute at comptime. There is no need to do this with an inline function, because the function is already being analyzed at the call site. The compiler will see that the result is comptime known, without having to promote the function to run at compile time.

The fix is that inline functions should never be implicitly promoted to run at comptime, regardless of their return type.