Hacker News new | past | comments | ask | show | jobs | submit login

> If you introduced to C++ a Result type

I don't know too much about the details of rust, but: std::optional? Whether people will use it is of course up to them, but my feeling is that they will.




Not the same, Optional is like Option in Rust, it’s about existence, not success or failure.

I believe std::expected is the correct answer but it’s unclear to me if it actually made it into the standard yet or not. I thought it had but can only find proposals...


AFAIK its not yet into any standards, possibly because the semantics are really complex (don't know how rust specifies them) - useful discussion here: https://www.reddit.com/r/cpp/comments/c75ipk/why_stdexpected...


Isn't Optional used in a lot of cases where empty means failure?


It might be, but that doesn’t make it semantically the correct thing.

As always, it depends. But traditionally, most languages that use this strategy have both, and they aren’t interchangeable. I can see this happening more when you only have optional, though.


That's not enough.

Hacking failure reporting into an existence API will make your code confusing, and will leave you no way to report multiple types of errors.


std::optional is like Rust's Option. But even then, without compile-time pattern-matching you leave the error to be checked at runtime, which defeats the purpose of this type. On top of that, it wouldn't be C++ if there wasn't some UB involved.


operator*() and operator->() on an empty std::optional is Undefined Behavior. This is mind-boggling. It defeats the whole purpose of using a wrapper type to enforce bulletproof error checking. It's the worst of both worlds: you have to use a cumbersome type, and it still fails like a nullable pointer.


yes, it is a somewhat baffling feature. the only practical use I can imagine for it is to avoid calling the copy constructor with an invalid instance of the type and/or to avoid a heap allocation. otherwise, it would be much more natural (and no less safe) for a c++ programmer to just use some flavor of pointer. in the case of pair<bool,T>, one would expect an optimizing compiler to skip the constructor call for an invalid instance anyway if the object was only accessed after checking the bool (unless the constructor has side-effects, yikes!).


I think most of this is just because C++ doesn't have very good pattern matching and didn't want to introduce new operators. (FWIW, using operator*() and operator->() feel very natural, although they are unsafe without using operator bool() as you have mentioned.)


from a safety perspective, std::optional is not much different than std::unique_ptr. both will happily allow you to invoke UB if you don't explicitly check for validity.


There are proposals for std::outcome and std::expected. I think the internal workings for one of them have also been passed to the C committee for standardisation.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: