Description
I think the "always_" prefixes of std.builtin.CallModifier.always_inline and .always_tail are redundant
Compare the following:
@call(.always_inline, function, .{argument}); @call(.@"inline", function, .{argument});Why do I need to say "always"? Inlining a function call or not is not some kind of probability thing that has a something-% chance of happening; it either happens or doesn't.
And if it couldn't happen, the compiler emits an error.
I'm guessing this relates to how an optimizer might decide to inline a function if it thinks that'd optimize the code, based on the case and the code around the call.
However why can't we just trust Zig here to inline the call if I say so and not if I tell it not to, regardless of optimizers? I don't think they play a role here.
If Zig doesn't call my function in the way I told it to (and doesn't emit a compile error), it might even lead to behavioral changes on my end so I don't think this is much different from other things, like my function returning if I tell it to using the return keyword. I should be able to trust Zig there. Otherwise, would it be alwaysreturn or pleasereturn?
Whatever I said about inlining applies to tail calling as well.
As for never_inline and never_tail, instead of "never" I think the meaning is simply "don't". So perhaps those should also be renamed, to no_inline and no_tail.
You can already find instances of "no_inline" and "no_tail" in the Zig codebase so the naming isn't unusual. As another precedent: the noinline keyword.
In fact if this is rejected, shouldn't std.builtin.CallModifier.compile_time be renamed to always_compile_time for consistency? Or the inline keyword to alwaysinline?