> I wish the standard had gone with a design that forces the developer to write an explicit check when unwrapping the optional...
If this is how std::optional worked, hardly anyone would use it.
If this is how std::optional worked, hardly anyone would use it.
OK... Well, this is how kj::Maybe works and having written several hundred thousand lines of code using it, I think it works well.
https://github.com/capnproto/capnproto/blob/master/kjdoc/tou...
The actual implementation of Maybe doesn't seem to force anything, it just returns a pointer to the stored value. There's no enforcement of any kind that anything is checked as a result. There's some hoop-jumping with friend classes to "hide" the readMaybe() function to make the non-macro usage as ugly as possible to strongly encourage using the macro-convention, but that's hardly "enforcement".
It's a cute syntax & macro pattern, but it's hardly a good fit for a C++ standard, either.
> There's no enforcement of any kind that anything is checked as a result. There's some hoop-jumping with friend classes to "hide" the readMaybe() function to make the non-macro usage as ugly as possible to strongly encourage using the macro-convention, but that's hardly "enforcement".
Sure fine. Anyone who wants to reach into the internal APIs could also just as easily do `#define private public` and bypass every protection C++ has. We're not trying to defend against malicious developers here.
See also value_or and the C++20 monadic methods on std::optional.
http://open-std.org/JTC1/SC22/WG21/docs/papers/2021/p0798r6....