Except that the counter can be adjusted by users.
> You can't really "generate code" in these dedicated build steps. Kristoff is talking about generating data. you could maybe build an object file, but then it's bound in using c abi, statically, which we've already solved in this conversation.
So any code generated outside has to be sync? That's exactly what I thought.
But even if Zig only allowed people to generate only data, this is a pretty big limitation.
This may not be a problem now, but it does mean that as Zig programs grow, people will run into this problem. I suspect that this means that Zig will struggle more than C to scale, maybe even more than C++ or Rust.
> In the long run for zig, calling out to c abi, much less one which takes a function pointer, much less one which you happen to have as async, is going to be a rare enough operation that I think people aren't clamoring to go and use it
This assumes that people won't want to interface with software that isn't in Zig. This is another way that Zig will struggle to scale.
> Besides, you just quickly wrap it in noasync context and you're done
This sounds exactly like a special calling technique mentioned in the function colors post.
> (you can't pass a zig callconv function directly to a c abi callconv site without at least a tiny wrapper anyways).
And this also sounds exactly like a special calling technique.
So? You've changed the program, and now it's valid. (as my handle suggests) I was a math major: arbitrarily large but finite is a different category than infinite, and that makes all the difference in the world.
> his sounds exactly like a special calling technique mentioned in the function colors post.
No, but the seam between async and sync in most other implementations requires writing an entire event loop. In this case it's often a single keyword, six characters. At worst, you write an extra function header to wrap it.
It's not the extraness that matters, it's the pain of doing so. Hell, even go requires you write "go" in front of your function to run it asynchronously, and I don't think that this counts as "colored functions".
A program is defined to be invalid when it runs out of counters. Problem solved.
>Also, if you step out to dedicated build steps, then the compiler no longer has complete visibility into that code when analyzing.
You can't really "generate code" in these dedicated build steps. Kristoff is talking about generating data. you could maybe build an object file, but then it's bound in using c abi, statically, which we've already solved in this conversation.
>Also, what do you do if a user needs to pass a function pointer to a C function? I presume they must use a sync function? If so, that seems like a direct application of the function colors definition;
In the long run for zig, calling out to c abi, much less one which takes a function pointer, much less one which you happen to have as async, is going to be a rare enough operation that I think people aren't clamoring to go and use it, which fails one of the criteria for your function coloring list. Besides, you just quickly wrap it in noasync context and you're done (you can't pass a zig callconv function directly to a c abi callconv site without at least a tiny wrapper anyways).