3 ms·

Let me rephrase, you can't call it like any other function. In Zig, a function that does IO can be called the same way whether or not it performs async operati

• tcfhgj 10mo ago
  > In Zig, a function that does IO can be called the same way whether or not it performs async operations or not. no, you can't, you need to pass a IO parameter
  • messe 10mo ago
    You will need to pass that for synchronous IO as well. All IO in the standard library is moving to the Io interface. Sync and async. If I want to call a function that does asynchronous IO, I'll use: foo(io, ...); If I want to call one that does synchronous IO, I'll write: foo(io, ...); If I want to express that either one of the above can be run asynchronously if possible, I'll write: io.async(foo, .{ io, ... }); If I want to express that it must be run concurrently, then I'll write: try io.concurrent(foo, .{ io, ... }); Nowhere in the above do I distinguish whether or not foo does synchronous or asynchronous IO. I only mark that it does IO, by passing in a parameter of type std.Io.
    • tcfhgj 10mo ago
      what about non-io code?
      • messe 10mo ago
        What about it? It gets called without an Io parameter. Same way that a function that doesn't allocate doesn't get an allocator. I feel like you're trying to set me up for a gotcha "see, zig does color functions because it distinguishes functions that do io and those that don't!". And yes, that's true. Zig, at least Zig code using std, will mark functions that do Io with an Io parameter. But surely you can see how that will lead to less of a split in the ecosystem compared to sync and async rust?
        • tcfhgj 10mo ago
          > But surely you can see how that will lead to less of a split in the ecosystem compared to sync and async rust? not yet
        • torginus 10mo ago
          This creates the drill-down issue we see with React props where we have to pass objects around in the call chain just so that somewhere down the line we can use it. React gets around this with the context hook and which you can access implicitly if it has been injected at a higher level. Do you know if Zig supports something of the sort?
          • messe 10mo ago
            It doesn't and likely never will. This has been a non-issue for years with Allocator. I fail to see why it will be a problem with IO.
            • throwaway17_17 10mo ago
              I think the view that it’s a non-issue comes down to familiarity via language usage. I am on the ‘everything explicit all the time’ team and see no issues with Allocator, or the proposed IO mechanism. But, programmers coming from other languages, particularly those with an expectation of implicitness being a semantic and syntactic feature can not envision programming without all of the alleged time saving/ergonomic ‘benefits’. I have had multiple ‘arguments’ about the reasoning advantages, complete lack of time loss (over any useful timeframe for comparison), and long-term maintenance benefits of explicitness in language design. I have never convinced a single ‘implicit team’ dev that I’m right. Oh well, I will keep doing what I do and be fine and will support in whatever ways I can languages and language development that prioritizes explicitness.
            • rowanG077 10mo ago
              Well it's not a "problem" in the sense that it's a blocker. But it's also not an improvement over standard async await in other languages. Which is not bad, don't get me wrong.