4 ms·

Note that in your updated example, `add2` has the exact same machine code in all build configurations. It's the calling code that is different - it has some eas

Note that in your updated example, `add2` has the exact same machine code in all build configurations. It's the calling code that is different - it has some easily-optimizable shims that allow passing the frame type to another function which expects such a type. You have a misleading variable name there: var frame = add2(a, b); return frame; It's not a "frame", it's just the i32 result of adding 2 numbers. This should be changed to: return add2(a, b); Or if you wanted to be very explicit: const result: i32 = add2(a, b); return result; The only thing I wanted to point out in the grandparent is that a function is async if and only if it yields. You can see from your godbolt example that `add2` is the same machine code in both code examples, because it does not yield.

yellowapple 6y ago
> 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.

yellowapple 6y ago

> 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.