The drawback I see of using a third-party solution for this is interoperability with other libraries. Rust's Optional and Result are especially great because they are part of the standard library, thus almost every project uses the same Result type. No need to define conversion operators.
They're part of Rust's core library. So they're available even when the full standard library isn't. Indeed core::option::Option is in effect a Lang Item, library components which are required to exist by the Rust language itself, as somebody pointed out to me on HN previously (technically Some and None are Lang Items, but well, they need to be the same type, so while an imaginary Rust implementation could name it Maybe or something instead of Option, that type needs to exist or the language can't happen at all)
C++ freestanding a) is barely supported, it's completely normal for a compiler vendor, e.g. Microsoft, to just decide they will not offer this at all and b) full of holes, so e.g. std::optional isn't provided in the freestanding library.
As a result, there isn't this same ubiquity in C++ for low level work. The language's built in types are garbage, and most of the standard library isn't available. Historically you had no choice, it's this rubbish or nothing, but Rust and to some extent Zig make that no longer true for a gradually increasing range of targets. Some C++ people have woken up and tried to improve freestanding because "We're terrible but there's no other choice" stops being a good sales pitch once your users have other Options. So I expect C++ 26 freestanding will be more useful and perhaps even better supported, for whatever that's worth.
The documentation seems nice as well...except I can't seem to find a link to the code itself. I have to believe it's right in front of me and I'm just not seeing it.
it's just a small wrapper around absl. Overal, the library just seems to reimplement or wrap a lot of stuff for no apparent reason
you aren't crazy, I also thought it was very weird that there weren't any links
The C++ standard library already exposes a std::optional type. Does this stx::Option type differ from that one?
std::optional is a stack pointer, like other C++ pointers you can straight up deref’ it and get an UB.
It looks like stx::Option is an actually option type, it focuses on safety and will throw if “unsafe” methods are called on the wrong state. It also provides a slew of monadic operators to operate over values.
I haven’t looked at the code but the stx documentation said it doesn’t use exceptions.
They explain it there: "No RTTI, memory allocation, nor exceptions."
Basically, nothing that has significant "runtime" cost....dynamic_cast, new/malloc, throwing exceptions.
In C++ this makes less sense because their standard library does have a defined "freestanding" subset but it doesn't make a very coherent whole, it's roughly the bits that seemed obviously to just not need any other components to work. It changes from version to version. And this stx library replaces what you might think of as core ideas, like an optional type, so you don't keep the shared vocabulary benefit.
[Edited to correct "standalone" to "freestanding"]
I'd always assumed rust may have taken this from C compiler arguments like -nostdlib / -nostdinc (and corresponding C++ ones -nostdlib++, -nostdinc++).
