5 ms·

Agreed and I actually don't really care about the GC speed. I mostly use arenas / object pools and you can do that with or without GC. Sort of undecided on the

Agreed and I actually don't really care about the GC speed. I mostly use arenas / object pools and you can do that with or without GC. Sort of undecided on the exceptions though. The Result / Option type in Rust is pretty nice to use (and !?*T in Zig, which is nicer if you ask me). It forces you to handle exceptions explicitly which is pretty nice and you can be sure there is no overhead introduced by the compiler for handling exception stuff. I'd probably wrap all the exception throwing functions in my D codebases with Result type if we had language level support for sum types and match syntax. I know we have it in the standard library, I want it in the language with nicer syntax. I also want the GC to be replaced with deterministic destruction using RC + ownership analysis and optimizations like Lobster does, but that's wishful thinking territory.

mhh__ 4y ago
Even if it's small, the Option/Result style exceptions always have overhead in at least a limiting case whereas the unwinding style exceptions are basically zero cost with a modern compiler - the debt is paid in the implementation being tricky.
- generichuman 4y ago
  > unwinding style exceptions are basically zero cost with a modern compiler - the debt is paid in the implementation being tricky. D doesn't return values when an exception is thrown as far as I know. How are exceptions' costs are paid by tricky implementation? I thought exceptions require allocation and run-time type info and therefore always introduce some cost (this goes for D and C++). I guess returning values and allocating error strings statically can help with that (or maybe allocate some exception buffer on program start -- but that's technically "overhead"). Am I wrong, or missing some important context related to exceptions?
  - mhh__ 4y ago
    If you don't throw there's no overhead, hence Exception-al cases only. The Optional style always has an overhead but the cost of actually throwing is much less. Lots of people do statically allocate their errors now. Implementing stack unwinding properly is not trivial.

mhh__ 4y ago

Even if it's small, the Option/Result style exceptions always have overhead in at least a limiting case whereas the unwinding style exceptions are basically zero cost with a modern compiler - the debt is paid in the implementation being tricky.

generichuman 4y ago
> unwinding style exceptions are basically zero cost with a modern compiler - the debt is paid in the implementation being tricky. D doesn't return values when an exception is thrown as far as I know. How are exceptions' costs are paid by tricky implementation? I thought exceptions require allocation and run-time type info and therefore always introduce some cost (this goes for D and C++). I guess returning values and allocating error strings statically can help with that (or maybe allocate some exception buffer on program start -- but that's technically "overhead"). Am I wrong, or missing some important context related to exceptions?
- mhh__ 4y ago
  If you don't throw there's no overhead, hence Exception-al cases only. The Optional style always has an overhead but the cost of actually throwing is much less. Lots of people do statically allocate their errors now. Implementing stack unwinding properly is not trivial.