3 ms·

You don't need to change the language. You need to add new functions to the standard library. There are already quite a few versions of older functions, with an

You don't need to change the language. You need to add new functions to the standard library. There are already quite a few versions of older functions, with an "_r" suffix in their names (from the top of my head, strtok_r(), although that is not a great example) that take an explicit pointer to local state, eliminating global state. You could just make more of them if you want to eliminate errno. > It a question of abstractions introduced to the language and the program at question. I don't think these kind of abstractions are in the spirit of C. As it says in the Charter linked here, "provide only one way to do an operation". A more acceptable way to me would be allowing multiple return values in general. But maybe there are technical reasons why this is not done. Or it has to do with the complexities that such a mechanism would add to the expression syntax.

vkazanov 8y ago
I absolutely agree about the multiple return values in general. Unfortunately the discussion around N2289 is more about providing something a lot like exceptions for both C and C++ but without all the exception problems. The proposal really has some ugly corners related to how one actually handles the errors. You can read the discussion here: https://www.reddit.com/r/cpp/comments/9owiju/exceptions_may_finally_get_fixed/ https://www.reddit.com/r/cpp/comments/9owiju/exceptions_may_...
Rusky 8y ago
The error handling proposal adds multiple return values- not as records/tuples, but as a sum type so only one can be returned from any given call. This could certainly be made more general, or just done via tagged unions (the way multiple return values can be done via structs), but there are massive advantages to be had by building it into the language and calling convention. The implementation can be far more efficient than any of a) the standard `int f(ret *out)` idiom, b) using errno, or c) some sort of `struct my_tagged_union f()` (which nobody uses anyway because it's a huge pain syntactically). In addition to being cheaper, the proposed built-in version of (c) is also syntactically simple enough to become a standard, shared mechanism.
- jstimpfle 8y ago
  > The implementation can be far more efficient Really, really hard to believe. Not only since returning unions is already legal (isn't it)? What function do you have in mind where an explit error-return-pointer argument is not close to maximally efficient?
  - Rusky 8y ago
    The first problem is that the error-return-pointer-argument approach must go through memory, because the caller can request that the return value go anywhere at all. The second problem is that existing calling conventions for `struct { bool tag; union { .. }; }` put everything in memory anyway, using a hidden pointer argument. Further, there's no way to put this type in the standard library because C doesn't have generics. The new implementation can put that single-bit tag in the CPU's carry flag where it has dedicated branch instructions and doesn't interfere with other values. It can leave the actual return value in a register without any kind of union aggregate lowering. So far this is all just calling convention tweaks, and could be done by pattern-matching user-defined tagged unions, but building it into the language a) makes it possible to standardize its semantics and connect it to platforms' C ABIs so other languages can also participate and b) makes it far simpler to implement and use so it's actually likely to be adopted.
    - jstimpfle 8y ago
      Why would it matter that the return-pointer write goes through memory? It's a handful of cycles. I'm curious what kind of function you envision that is so short-lived AND needs tricky error handling AND is extremely performance-sensitive.
      - Rusky 8y ago
        All of them- it adds up. Calling conventions are a perfect place for this kind of microoptimization, because they apply pervasively and (assuming you want better error handling support) without additional change to program source. The same reasoning applies to putting effort into register allocators, or switching from setjmp/longjmp to table-based unwinding, etc.

vkazanov 8y ago

I absolutely agree about the multiple return values in general. Unfortunately the discussion around N2289 is more about providing something a lot like exceptions for both C and C++ but without all the exception problems. The proposal really has some ugly corners related to how one actually handles the errors. You can read the discussion here: https://www.reddit.com/r/cpp/comments/9owiju/exceptions_may_finally_get_fixed/ https://www.reddit.com/r/cpp/comments/9owiju/exceptions_may_...

Rusky 8y ago

The error handling proposal adds multiple return values- not as records/tuples, but as a sum type so only one can be returned from any given call. This could certainly be made more general, or just done via tagged unions (the way multiple return values can be done via structs), but there are massive advantages to be had by building it into the language and calling convention. The implementation can be far more efficient than any of a) the standard `int f(ret *out)` idiom, b) using errno, or c) some sort of `struct my_tagged_union f()` (which nobody uses anyway because it's a huge pain syntactically). In addition to being cheaper, the proposed built-in version of (c) is also syntactically simple enough to become a standard, shared mechanism.

jstimpfle 8y ago
> The implementation can be far more efficient Really, really hard to believe. Not only since returning unions is already legal (isn't it)? What function do you have in mind where an explit error-return-pointer argument is not close to maximally efficient?
- Rusky 8y ago
  The first problem is that the error-return-pointer-argument approach must go through memory, because the caller can request that the return value go anywhere at all. The second problem is that existing calling conventions for `struct { bool tag; union { .. }; }` put everything in memory anyway, using a hidden pointer argument. Further, there's no way to put this type in the standard library because C doesn't have generics. The new implementation can put that single-bit tag in the CPU's carry flag where it has dedicated branch instructions and doesn't interfere with other values. It can leave the actual return value in a register without any kind of union aggregate lowering. So far this is all just calling convention tweaks, and could be done by pattern-matching user-defined tagged unions, but building it into the language a) makes it possible to standardize its semantics and connect it to platforms' C ABIs so other languages can also participate and b) makes it far simpler to implement and use so it's actually likely to be adopted.
  - jstimpfle 8y ago
    Why would it matter that the return-pointer write goes through memory? It's a handful of cycles. I'm curious what kind of function you envision that is so short-lived AND needs tricky error handling AND is extremely performance-sensitive.
    - Rusky 8y ago
      All of them- it adds up. Calling conventions are a perfect place for this kind of microoptimization, because they apply pervasively and (assuming you want better error handling support) without additional change to program source. The same reasoning applies to putting effort into register allocators, or switching from setjmp/longjmp to table-based unwinding, etc.