Using std::expected if compiled with C++23

[jowillianto]

I am suggesting that this library be made up to date with newer standards. Hence
For people compiling with c++20, we can either :

• use rfl::Result
  or
• use std::expected by including the header
  And for people compiling on C++23 or higher :
• use std::expected<..., rfl::Error> for all.

[jowillianto]

This is just a discussion, but adding this will mean we will need to use macros but its use can be localized to only one file and exporting something like

using rfl::Result = ...

or not use macro and use cmake to add the expected header for people compiling on C++ 20. This will ensure that the library is compatible with C++20 and be up to date to newest C++ standards.

[liuzicheng1987]

@jowillianto , yeah, I was thinking about this as well. In fact, I designed rfl::Result with std::expected in mind.

We could simply use __cpp_lib_expected:

#ifdef __cpp_lib_expected

template<class T>
using rfl::Result = std::expected<T, rfl::Error>;

#else

...

#endif 

[jowillianto]

Should I look to implement it ?
Also, there is a little semantics difference I saw in the implementation of rfl::Result in that it is actually equivalent to :

template <typename T>
using rfl::Result = std::expected<T, std::optional< rfl::Error> >;

I am not sure about why the design decision for rfl::Result is as such. However I believe :

template<class T>
using rfl::Result = std::expected<T, rfl::Error>;

is a better design choice.

[liuzicheng1987]

@jowillianto why do you think that? I don't think you have to wrap it in an optional.

Sure, go ahead, implement it.

[liuzicheng1987]

@jowillianto, I see what you mean...because calling error() on std::expected when it actually contains a value is undefined behaviour whereas we just return std::nullopt, so it is very defined.

I think you could just adapt that to the standard.

[jowillianto]

Ah I see. So that is the intention, changing semantics could break backwards compatibility, how should we act on this issue ?

I.e.
using rfl::Error vs std::optional<rfl::Error> is two different semantics

[liuzicheng1987]

@jowillianto , just break our API...I think it's very a small change, we are technically still in beta and conforming to the standard library is more important.

[jowillianto]

Ok. I will try to work on this throughout the weekend

[liuzicheng1987]

If you have any questions, let me know

[BestITUserEUW]

@jowillianto have you already worked on this, or are you planning to work on it soon?

If not, i would work on it on the weekend.

[jowillianto]

I am working on it ! Going to be done soon !