Better align 'iox::expected' with 'std::expected'

[elBoberido]

Brief feature description

Currently the iox::expected differs from the newly introduced C++23 std::expected. To make it easier for developer already familiar with std::expected the custom implementation in iceoryx should be aligned where possible.

Detailed information

In scope:

• implicit conversion from T -> we will not have implicit conversion; for safety code it is better to be explicit
• default ctor creates an expected with a T if T has a default ctor -> we will not have default ctors; for safety code it is better to be explicit
• introduction of iox::unexpected, iox::unexpect_t and iox::unexpect
• introduction of iox::ok(...) and iox::err(...) as convenience function due to missing CTAD in C++14
• rename and move of iox::success and iox::error to iox::detail::ok and iox::detail::err
• remove static iox::expected<T, E>::create_value and iox::expected<T, E>::create_error in favor of ctors with iox::in_place and iox::unexpect
• introduction of iox::expected<T, E>::has_value
• introduction of iox::expected<T, E>::value and deprecation of iox::expected<T, E>::get_value
• introduction of iox::expected<T, E>::error and deprecation of iox::expected<T, E>::get_error

Out of scope

• introduction of transform
• aligning of the semantics of and_then and or_else

[mossmaurice]

@elBoberido Thanks for creating the issue! 🙏 Do you also see possible extensions like a try operator macro in the scope of this issue?

default ctor creates an expected with a T if T has a default ctor

I don't think having a default c'tor with expected is a good idea. An expected should always have a clear state. IMHO the committee did a mistake here.

[elBoberido]

@mossmaurice this is just a proposal and we can omit some of the ctors or implicit conversion if we deem them unfit for safety. A try macro would be done in a separate issue. This is mainly for the alignment with the std::expected