libCat VS expected

That's awesome! I'm working on something that sounds similar. https://github.com/cons-cat/libcat

I'd love to see your work if you're willing to share it here!

It's worse in the standard library than it has to be. When I refactored my traits to minimize template instantiations and lean on concepts as much as possible, I measured over 30% improvement to clean build compile times. It's not possible for the standard to do this, because it would subtly change the API. For instance, you can't instantiate or take the address of a concept, but you can for a type-trait class. No reason you'd want to do that, but you can, so they can't "break" the standard library by optimizing this.

This doesn't have to be true. Over the past year I've made progress towards demonstrating how even non-freestanding C++ can be written without any C or C++ standard library headers or DLLs (with large benefits). There are a few names which the compilers require to be in the std:: namespace, though, but they're very special features like source_location and construct_at with semantics that can't be expressed otherwise.

It isn't that hard to put a predicate into a type. We have lambdas in an unevaluated context, CTAD, and templated type aliases. https://github.com/Cons-Cat/libCat/blob/main/src/libraries/scaredy/cat/scaredy https://github.com/Cons-Cat/libCat/blob/main/src/global_includes.hpp#L70 https://github.com/Cons-Cat/libCat/blob/main/src/libraries/linux/cat/linux#L289 You do it like this.

I use clang-tidy. These are my current linting rules.

I'm working on this! https://github.com/Cons-Cat/LibCat

In the meantime, I may use the TartanLlama implementation (here) and plan around replacing it with the real deal in the near future.

outcome and/or expected

Eventually you'll be able to use std::expected in C++23!

https://en.cppreference.com/w/cpp/header/expected

Don't throw exceptions, require the caller to handle errors and propagate them up the stack (everything returns an expected) if they cannot be handled. You are forced to model the error domains instead of just throwing an exception and assuming the caller knows to catch it and do something with it.

Java has checked exceptions, but, Kotlin decided to abandon them.

The nice codebases I have worked on stick to the Result type in Swift or Kotlin. And thus you are forced to 'translate' errors (exceptions?) as described in Alan Griffith's 'Exceptional Java'.

https://accu.org/journals/overload/10/48/griffiths_406/

"If a checked exception is thrown (to indicate an operation failure) by a method in one package it is not to be propagated by a calling method in a second package. Instead the exception is caught and "translated". Translation converts the exception into: an appropriate return status for the method, a checked exception appropriate to the calling package or an unchecked exception recognised by the system. (Translation to another exception type frequently involves "wrapping".)"

If you can't wait for C++23, there's a single header implementation here.

https://github.com/TartanLlama/expected

Exception is part of std, (ex. in std::vector constructor). Exceptions should be used in the "everything is lost" situation. In a situation where exceptions are not activated, the overhead is close to zero. For the rest there is expected (https://github.com/TartanLlama/expected)

hmm, well had std::expected been standardised, i would have suggested that. if the op is ok, perhaps this might be worth checking out?

There is a proposal for std::expected that contains either a value or an error type. It has a rich interface that allows a wide variety of uses and can prevent lots of duplicated error-checking code. Sy Brand has created a working implementation. code docs

Also worth to check this implementation in my opinion: https://github.com/TartanLlama/expected

If one is willing to use something outside of std, there are even better options than std::variant, like expected or Boost.Leaf.