4 ms·

Show HN: Cppmatch – Rust-Like Pattern Matching and Error Handling for C++

42 points by Rucadi 2y ago

I've created cppmatch, a lightweight, header-only C++ library that brings Rust-inspired pattern matching and error handling to C++. It tries to imitate the functionality of the questionmark (?) operator in C++ by using a macro that uses the gcc extension https://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html https://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html This allows to create exceptionless code with non-intrusive error-as-value that unlike Exceptions, makes it clear which kinds of error a function can generate and forces you to handle (or ignore) them. The ? operator translates to *expect* To handle the errors I introduce *match* which allows to easily visit the contents of the result or any std::variant (you can use it to imitate rust enums) You can view an example of this project used in a "real way" in compiler-explorer: Simplified error types to just be a string: https://compiler-explorer.com/z/6j3866E7W https://compiler-explorer.com/z/6j3866E7W Multiple structs as error types: https://compiler-explorer.com/z/encbf5f43 https://compiler-explorer.com/z/encbf5f43 Feel free to give feedback or contribute to the project!

bestouff 2y ago
Please leave that Frankenstein of a language alone. Stop bolting features on it, it's already a monster.
Wumpnot 2y ago
[flagged]
j1elo 2y ago
This is great! Thanks for sharing, it is a cool idea to try bringing QoL improvements from Rust to C++. Got a question: Does this prevent the RVO/NRVO compiler optimizations for return values? And when those fail, same question for the move-construction for types that do have a move constructor.
- Rucadi 2y ago
  RVO/NRVO are valid and are not affected. We are dealing with std::variant, and the move semantics are defined by the alternative. https://en.cppreference.com/w/cpp/utility/variant/operator%3D https://en.cppreference.com/w/cpp/utility/variant/operator%3...
senkora 2y ago
Have you considered using the immediately invoked function expression (IIFE) pattern as a standards-compliant alternative to gcc statement expressions?
- Rucadi 2y ago
  The main problem with IIFE is the same as with a normal function: You cannot return the caller function from inside the closure, making the "short-circuit" mechanism provided by questionmark (?) operator not possible. With the GCC Extension, we get around that using a construct that is pretty similar to IIFE, it allows to return a value from an immediate expression created by a block of code that is surrounded by ({}) The nice thing about this block ({}) is that the last statement is used as the "return value" without an explicit return, this disambiguates between the "expression" return and the "function" return. Without compiler support, the short-circit is not possible, but with this feature + macros we can create a function that behaves like that.
  - Rucadi 2y ago
    Regardless of that, the only function that requires this extension is the "except" macro, if you are willing to not short-circuit, you can still use the other functionality of this library.
    - senkora 2y ago
      Makes sense, thank you!
nickysielicki 2y ago
https://libfn.org/ https://libfn.org/ also is worth a look.
- exradr 2y ago
  At a glance, looks good, but it really needs some better documentation! It doesn't seem to include anything similar to this project's expect macro though.

42 points by Rucadi 2y ago

bestouff 2y ago

Please leave that Frankenstein of a language alone. Stop bolting features on it, it's already a monster.

Wumpnot 2y ago

[flagged]

j1elo 2y ago

This is great! Thanks for sharing, it is a cool idea to try bringing QoL improvements from Rust to C++. Got a question: Does this prevent the RVO/NRVO compiler optimizations for return values? And when those fail, same question for the move-construction for types that do have a move constructor.

Rucadi 2y ago
RVO/NRVO are valid and are not affected. We are dealing with std::variant, and the move semantics are defined by the alternative. https://en.cppreference.com/w/cpp/utility/variant/operator%3D https://en.cppreference.com/w/cpp/utility/variant/operator%3...

senkora 2y ago

Have you considered using the immediately invoked function expression (IIFE) pattern as a standards-compliant alternative to gcc statement expressions?

Rucadi 2y ago
The main problem with IIFE is the same as with a normal function: You cannot return the caller function from inside the closure, making the "short-circuit" mechanism provided by questionmark (?) operator not possible. With the GCC Extension, we get around that using a construct that is pretty similar to IIFE, it allows to return a value from an immediate expression created by a block of code that is surrounded by ({}) The nice thing about this block ({}) is that the last statement is used as the "return value" without an explicit return, this disambiguates between the "expression" return and the "function" return. Without compiler support, the short-circit is not possible, but with this feature + macros we can create a function that behaves like that.
- Rucadi 2y ago
  Regardless of that, the only function that requires this extension is the "except" macro, if you are willing to not short-circuit, you can still use the other functionality of this library.
  - senkora 2y ago
    Makes sense, thank you!

nickysielicki 2y ago

https://libfn.org/ https://libfn.org/ also is worth a look.

exradr 2y ago
At a glance, looks good, but it really needs some better documentation! It doesn't seem to include anything similar to this project's expect macro though.