Skip to content(if available)orjump to list(if available)

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

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

10 comments

·March 16, 2025

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

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

Multiple structs as error types: https://compiler-explorer.com/z/encbf5f43

Feel free to give feedback or contribute to the project!

nickysielicki

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

exradr

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.

j1elo

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

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%3...

senkora

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

Rucadi

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

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

Makes sense, thank you!

Wumpnot

[flagged]

bestouff

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