Use std::expected for outcome when available

[jb-gcx]

Motivation

Using std types when possible increases compatibility with other codebases.

Considerations

• I've removed make_unexpected because it is unnecessary in my environment. Are there issues on other compilers with type deduction for unexpected?
• I tested the code with real devices on iOS and Android
• I was unable to test the code with a compiler that does not support std::expected (ie does not define the feature flag). I can offer a godbolt link to show the basic feature check works (just switch to -std=c++20 to see that supported changes to false). I can probably create a setup to test this properly, but if someone else already has such a setup I would greatly appreciate some support.
• I did not test the wasm and ts adapters.
• This changes behavior of existing code in environments where std::expected is available. I'd argue it does so in unproblematic ways:
  • The codebase used djinni::expected everywhere - the change should be unnoticable.
  • The codebase used std::expected in some places and djinni::expected in others. This change would make any conversion code between the two types obsolete, but should not break anything, since djinni::expected now just maps to std::expected.
  • The codebase used tl::expected in some places and djinni::expected in others. This is the only problematic case, though the solution is simple: use std::expected or djinni::expected.

[LiFengSC]

Thanks for your contribution. I think make_unexpected() used to be necessary to make it work in C++14. Class template argument deduction is a C++17 feature. Snap's codebase is currently at C++20 so I think it is fair now to drop C++14 support.

[jb-gcx]

Sounds good, thanks for the feedback 👍

Let me know if there is anything else for me to do to get this merged.

[LiFengSC]

One last request: Lets keep the make_unexpected helper function in both code paths:

#ifdef __cpp_lib_expected

#include <expected>

namespace djinni {

using ::std::expected;
using ::std::unexpected;

template <class E>
unexpected<typename std::decay<E>::type> make_unexpected(E &&e) {
    return unexpected {std::forward<E>(e)};
}

}

#else

#include "tl_expected.hpp"

namespace djinni {

using ::tl::unexpected;
using ::tl::expected;
using ::tl::make_unexpected;

}

#endif

the make_unexpected function is already used in many places in Snap's codebase. If we keep it then it mean there is zero change needed on user side. We can also remove the changes in the marshallers in this PR.

C++20 code can directly use unexpected constructor and ignore the helper function.

[jb-gcx]

I saw your comment via eMail and didn't realize you had posted code until I pushed my changes and checked the PR. I hope my way of reintroducing the helper is also acceptable?

I also added the type_traits and utility headers, because they're technically required for std::forward and std::decay. Although they seem to already have been included transitively anyway.

I've force pushed to avoid merging fixup commits, I think the changes are small enough that this won't cause confusion.

[LiFengSC]

No problem, I like the way you did it.