support both inline keyword as well as callconv(.Inline)

[tadeokondrak]

accepted proposal

---

inline is mutually exclusive with a custom calling convention, I think this makes it simpler.
noinline is unaffected.

[andrewrk]

This is a change we can get zig fmt to do for us automatically.

[nektro]

what about the inconsistency this now causes with inline for ?

that being inline for being to unwrap loops, and then inline fn being for unwrapped funcions

[windows-h8r]

what about the inconsistency this now causes with inline for ?

that being inline for being to unwrap loops, and then inline fn being for unwrapped funcions

@nektro I agree with you. To make matters worse, noinline remains, and #7772 is accepted. Even more inlineed things.

[SpexGuy]

I agree, I think there's a difference in stage 2 between a semantic inline and a machine code inline. Machine code inline is a calling convention, semantic inline is maybe something else. It may make sense to have both.

[frmdstryr]

Any function that uses an async call cannot be explicitly inlined now:

error: function with calling convention 'Inline' cannot be async

[LemonBoy]

The asymmetry with noinline is really bad, I'd reconsider this change before the next release.

[andrewrk]

I have a completely feelings-based reaction to this, I can't justify it other than emotions.

inline fn makes me happy
callconv(.Inline) makes me cringe

[ikskuh]

@andrewrk inline isn't really a calling convention anyways, but a semantic transformation, so it's kinda misleading to have it as a calling convention. At least if i understood @SpexGuy correctly

[jedisct1]

I miss inline fn as well.

[tadeokondrak]

I agree with the switch back,

inline isn't really a calling convention anyways, but a semantic transformation

I only learned after this was implemented that this was the plan in stage2.

[frmdstryr]

inline fn makes me happy
callconv(.Inline) makes me cringe

You are not alone... will be glad when inline is back.

[marler8997]

If we went back to inline fn, would it be an error to specify both inline and an explicit calling convention? Same thing for noinline (since a function with a calling convention can't be inlined anyway)?

[nektro]

having it as callconv is nice because then you don't have to add a check to make sure inline/noinline is being used with incompatible callconvs, such as .C

[nektro]

whether or not it counts as a callconv or not I guess depends on exactly how callconv is defined. Is callconv just how something is used with respect to an ABI or is it a little more abstract? because if its the latter then inline is a callconv because instead of calling the function like normal on the stack, it becomes somewhat analogous to #define functions

[marler8997]

If we kept it as callconv, then noinline could also be moved to a calling convention. We could consider the default calling convention as "inlineable" and use something like callconv(.NoInline) to override it. Note that both "inline" and "noinline" are not compatible with any other calling convention as far as I can tell, so keeping these options all in the same set is the simplest way to represent them.

[andrewrk]

noinline cannot be moved to a calling convention because then you don't know what the calling convention is.

[marler8997]

I take my comment back. Apparently Zig is free to inline functions of any calling convention, which means the presence of "noinline" on a function can change the behavior of a function with any calling convention.

[nektro]

how is noinline used? the only mention I see of it in the lang reference is in the docs for @call

[LemonBoy]

how is noinline used

You put it on the declaration site, noinline fn foo() void { ... }

If we went back to inline fn, would it be an error to specify both inline and an explicit calling convention

It's an error because the chosen callconv annotation may require the backend to emit different machine code wrt a regular function (think of the .Interrupt or .Signal).

[andrewrk]

I'm making the call here, Zig will support both inline fn syntax as well as callconv(...) syntax. It will be a compile error to have both inline and callconv syntax both specified.

As far as one way to do things goes, here's the one way to do things:

• use inline fn when you can
• use callconv(...) when you must

[nektro]

when you can

are there any notable situations where would *not* be able to?

[LemonBoy]

use callconv(...) when you must

I can't think of a single instance where one would use this over inline

[ifreund]

I can't think of a single instance where one would use this over inline

using callconv(...) allows you to inline or not based on a comptime known value. I don't have a use-case for this though.

Anyhow, I intend to implement the revised proposal today and make zig format replace callconv(.Inline) with the inline keyword if the enum literal is used directly.