4 ms·

> They are just error return type https://wg21.link/p2544#expected https://wg21.link/p2544#expected >> the overhead is so high that std::expected is not a goo

> They are just error return type https://wg21.link/p2544#expected https://wg21.link/p2544#expected >> the overhead is so high that std::expected is not a good general purpose replacement for traditional exceptions. I'm guessing you don't care about performance that much.

feznyng 2y ago
You might be right, but it doesn't seem correct to extrapolate that Zig's error return type is slow just because C++'s is. If Zig was designed with this kind of error handling from the start, it may well have optimized for it.
- dataflow 2y ago
  > You might be right, but it doesn't seem correct to extrapolate that Zig's error return type is slow just because C++'s is. If Zig was designed with this kind of error handling from the start, it may well have optimized for it. It seems pretty correct to me? It's just based on first principles. Returning a value + error is strictly more work than returning just a value, and compilers can't solve the halting problem to optimize away arbitrary amounts of extra work. Ergo, performance hit.
  - MobiusHorizons 2y ago
    Comparing zig error handling to no error handling is a bit disingenuous. Error handling does work and therefore costs something. This whole thread is about how exceptions are very expensive when thrown. The question then becomes how different error handling strategies handle real workloads (which will include some percentage of error cases)
    - dataflow 2y ago
      > Comparing zig error handling to no error handling is a bit disingenuous. I'm comparing in-band to out-of-band error signaling, not "error handling to no error handling".
- kllrnohj 2y ago
  You can't really "optimize" that every function call now has a branch after it to check for an error. That's a design choice Zig made at the cost of performance, which is not inherently bad. After all, lots of languages intentionally sacrifice performance for some other benefit. But those types of choices are not things you can just waive a magic wand at later to hope it goes away.
lukaslalinsky 2y ago
I stand corrected then, I didn't realize exceptions are this cheap. That's good to know.

feznyng 2y ago

You might be right, but it doesn't seem correct to extrapolate that Zig's error return type is slow just because C++'s is. If Zig was designed with this kind of error handling from the start, it may well have optimized for it.

dataflow 2y ago
> You might be right, but it doesn't seem correct to extrapolate that Zig's error return type is slow just because C++'s is. If Zig was designed with this kind of error handling from the start, it may well have optimized for it. It seems pretty correct to me? It's just based on first principles. Returning a value + error is strictly more work than returning just a value, and compilers can't solve the halting problem to optimize away arbitrary amounts of extra work. Ergo, performance hit.
- MobiusHorizons 2y ago
  Comparing zig error handling to no error handling is a bit disingenuous. Error handling does work and therefore costs something. This whole thread is about how exceptions are very expensive when thrown. The question then becomes how different error handling strategies handle real workloads (which will include some percentage of error cases)
  - dataflow 2y ago
    > Comparing zig error handling to no error handling is a bit disingenuous. I'm comparing in-band to out-of-band error signaling, not "error handling to no error handling".
kllrnohj 2y ago
You can't really "optimize" that every function call now has a branch after it to check for an error. That's a design choice Zig made at the cost of performance, which is not inherently bad. After all, lots of languages intentionally sacrifice performance for some other benefit. But those types of choices are not things you can just waive a magic wand at later to hope it goes away.

lukaslalinsky 2y ago

I stand corrected then, I didn't realize exceptions are this cheap. That's good to know.