PragmaTwice commented on PR #768: URL: https://github.com/apache/incubator-kvrocks/pull/768#issuecomment-1211661509
> C++23 std::expected [2] is used to contains expected value or an error, does this a more generic way, Can we implement same thing like this. We can combine Status and the expected class do the things StatusOr does. Hi @wy-ei , `StatusOr<T>` has same purpose and similar implementation with `std::expected<T, E>`. Actually I has implemented something equal to `std::expected` for [oneflow](https://github.com/Oneflow-Inc/oneflow), and you can find its source code [here](https://github.com/Oneflow-Inc/oneflow/tree/master/oneflow/maybe), `oneflow::maybe::Maybe<T, E>`, `oneflow::maybe::Variant<T...>` and `oneflow::maybe::Optional<T>` is the basic error handling method in oneflow. But obviously, the implementation of `std::expected` is only more complicated and difficult to understand, while the implementation of `StatusOr` is relatively simple. > For StatusOr I have one question. StatusOr use a char[] to store T or Status, I don't known why, why don't use union? The same problem is faced with the union implementation, you also need to evaluate some conditions before calling the ctor dtor, so I don't see a difference. > The Status class implemented in leveldb only take 8 bytes (only one member which is const char *state_). If status is ok, state_ is nullptr, if status is not ok, the state_ store the error code and error message. If we change the Status implementation in kvrocks to the leveldb way, the size of Status is not a problem. I think it's only a little different from `std::unique_ptr<Status>` and performs worse than `StatusOr`, since error code is on the stack in `StatusOr`. > Another problem of Status for me is it occupy the place of the return value, we must pass a pointer to take the return value. Golang solve this problem by returning multi value. A sample and easily understand way is return a tuple or another Class will contain return value T and status. This is actually a huge flaw in golang: golang has no [sum type](https://en.wikipedia.org/wiki/Tagged_union). So in golang, only two values can be returned instead of expressing an "either .. or .." relationship. Of course, interface can achieve this, but it is obviously far more troublesome than sum type. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
