[DixieDev]

My original reply is kind of sloppy, here's a snippet to better illustrate my confusion: https://gitlab.com/-/snippets/2290425

Specifically, examine this:

  fn foo() void {
    bar();
    std.log.info("foo() is finished", .{});
  }

It looks dead simple, but it's a pain in the butt to use because it's actually async, and you can know neither that nor how to get this function to actually finish without looking inside of bar().

[samatman]

You can't know this function will actually finish without looking inside of bar() in any Turing Complete language, because this is the Halting Problem.

Not in a trivial way either. A good async language will never let std.log.info print until/unless bar resumes.

The difference between a "blue foo" and a "red foo" is also subtler than we pretend it is. Both will finish eventually, unless they don't, and both may be paused for as long as the OS wants in any preëmptive operating system.

[DixieDev]

Ok, sure, there are a whole bunch of reasons that my function might not actually finish. In this case, though, it's specifically not finishing due to invisible compile-time additions Zig is making to the function I've written.

They could instead require me to explicitly write `await bar();` within foo(), and I could find comfort in the "no hidden control flow" tenet of the language once more. I recognise now that this would break the colour-blindness of their async implementation and that this is a pretty significant trade-off, but my perspective remains that this breaks one of the rules they've laid out on their homepage.

[lostmsu]

Can I call foo from main and expect, that by the time program completes, info is logged? If not, I agree with GP - that is a very bad design.

[samatman]

No, you can't, not without knowing what is inside of bar().

bar() could contain an infinite loop. bar() could call rand() and try to reference the null pointer 1 in n times. bar() could issue forth nasal demons to haunt you. bar() could call os.exit. bar() could recurse until the stack is exhausted. bar() could suspend and not resume. The OS could kill bar() from outside before it returns.

Who knows what shadows lurk within a function's stack frame?

Run it and find out.

The invariant which needs to be preserved here is that if bar() returns, the log will print, and equally important, if bar does not return, the log will not print.

That's what a good async system can preserve without knowing what's inside bar.

[lostmsu]

OK, maybe I need to rephrase my question: if I do this in main, am I guaranteed to have "main" printed after "foo() is finished"

    foo();
    std.log.info("main", .{});

[kristoff_it]

That's how it works in Zig. Calling an async function like this will also await it.

[mkishi]

Could you share an example? I thought async functions weren't callable outside an `async` invocation from the `Inline` calling convention.

[DixieDev]

Within main(), your snippet will give you an error at compile time "function with calling convention 'Inline' cannot be async". In my snippet foo() is invoked in an async context using the async keyword, and when foo() suspends (due to it awaiting bar()) control will be returned to main(). If you change your first line from

  foo();

to

  _ = async foo();

Then your program will compile and your log is not going to be prevented by Zig's async shenanigans.

[samatman]

I would consider that necessary, but not sufficient, to call a particular async system "good", yes.