backport c++23 std::expected

[zhjwpku]

After studied [0], [1] and [2], I'm inclined to backport [0] to iceberg-cpp, the main reason is that [0] has exactly the same APIs as std::expected, [1] provide some extra member functions like map and map_error, [2] has different API names like then and thenOrThrow.

We want users to use iceberg::expected the same way as std::expected, and we will replace iceberg::expected with std::expected when we decide to move to c++23 some day, by backporting [0], we can facilitate a smoother transition process.

We discussed about Exceptions vs Expected in #14, while backporting [0], I had the feeling we shouldn't choose one over the other, we can use both approaches effectively.

expected provide monadic operations like and_then, transform, or_else, transform_error, let us do method chaining, which is a good sign.

[0] https://github.com/zeus-cpp/expected
[1] https://github.com/TartanLlama/expected
[2] https://github.com/facebook/folly/blob/main/folly/Expected.h
[3] https://en.cppreference.com/w/cpp/utility/expected

[lidavidm]

I think we have to update NOTICE and/or LICENSE when vendoring code?

[lidavidm]

LGTM. IMO let's get moving on this.

BTW, we could consider writing a custom check to just enforce [[nodiscard]] on functions returning expected? https://clang.llvm.org/extra/clang-tidy/Contributing.html

[zhjwpku]

LGTM. IMO let's get moving on this.

BTW, we could consider writing a custom check to just enforce [[nodiscard]] on functions returning expected? https://clang.llvm.org/extra/clang-tidy/Contributing.html

Reasonable, will file an issue once this PR got merged.

[wgtmac]

Is it possible to check the macro __cpp_lib_expected and directly use std::expected if available?

[pitrou]

Is it possible to check the macro __cpp_lib_expected and directly use std::expected if available?

That may lead to ABI issues. For example if iceberg-cpp is compiled using a C++20 compiler, and then an application links to it with C++23 enabled. Or the reverse.

[wgtmac]

That may lead to ABI issues. For example if iceberg-cpp is compiled using a C++20 compiler, and then an application links to it with C++23 enabled. Or the reverse.

Make sense. Thanks!

[zhjwpku]

@Fokko @Xuanwo I'd appreciate it if you could review this backport of std::expected. While we haven't yet decided whether to use expected over exception, having this backport ready could be beneficial for future feature implementation.

[wgtmac]

@pitrou @raulcd Do you have any comment on this PR?

[pitrou]

I'm surprised by the license header. Shouldn't we use the Apache license there and record the provenance elsewhere?

[zhjwpku]

I'm surprised by the license header. Shouldn't we use the Apache license there and record the provenance elsewhere?

Yes, that was the initial version. I adopted the ASF License and included the zeus-cpp License (MIT) in the NOTICE file. There is a line in the ASF License:

See the NOTICE file distributed with this work for additional information regarding copyright ownership.

I'm unsure if this is sufficient. @lidavidm suggested some references from Arrow, which led us to finalize the current version.

[lidavidm]

An Apache member corrected this in arrow-java by making sure vendored files had their original license header: apache/arrow-java#550