> You can see from your godbolt example that `add2` is the same machine code in both code examples, because it does not yield. Right, but ain't that the point:

> You can see from your godbolt example that `add2` is the same machine code in both code examples, because it does not yield. Right, but ain't that the point: that Zig functions themselves are neither sync nor async (they're "colorblind"), but rather it's just how they're called? I mean, I guess one way to "color" the function would be to have it suspend or do something with @frame() (more on that below...), but that (from what I'm seeing) only forces functions to be async, and doesn't seem to imply a function without that to not (potentially) be async. That is: the fact that the calling code is what's different is exactly my point. Nothing the function itself is doing is (I'd argue) what dictates whether or not it's "sync" or "async"; it's purely whether or not the caller is invoking it synchronously or asynchronously. Hence: a function can still be "async" even if it never yields. I think we just have different ideas of what "async" means (i.e. whether it's a property of the caller or callee); I'm arguing the former, for the same reason that I'd argue a function (or more precisely its invocation) to be "comptime" if it's executed within a comptime {...} block, regardless of whether or not the function itself is aware of this. Even excluding this particular angle, though (i.e. going with the convention of asyncness being callee-dependent), the docs have a couple¹ examples² of situations where an "async" function in Zig seemingly won't yield (due to a suspend that immediately resumes itself or due to simply invoking @frame without doing anything with it, respectively), and indeed both cases do appear to produce code¹ consistent with said cases not yielding (I certainly ain't resuming/awaiting anything in add(), and yet the return value is 3 as expected in either case, as opposed to 0⁴ if there's an actual yield before the arithmetic happens). ---- ¹: https://ziglang.org/documentation/master/#Resuming-from-Suspend-Blocks https://ziglang.org/documentation/master/#Resuming-from-Susp... ²: https://ziglang.org/documentation/master/#frame https://ziglang.org/documentation/master/#frame ³: https://godbolt.org/z/kby4vB https://godbolt.org/z/kby4vB ⁴: Tangent: I'd expect returning or otherwise trying to read an undefined value would produce a panic, yeah? Yet, in both debug and release-safe returning "result" from main() while it's set to "undefined" results in a 0 return value. Ain't sure if this is a bug or expected behavior.