commit | 5284bc2af27a41a11bf3952b8b3422bb7dc5357b | [log] [tgz] |
---|---|---|
author | Ryan Prichard <rprichard@google.com> | Wed Mar 06 23:59:57 2024 -0800 |
committer | Ryan Prichard <rprichard@google.com> | Thu Mar 21 23:59:36 2024 -0700 |
tree | e065fc681eb634d584ea748ed57add344214cd9b | |
parent | 398ff505b09500a6f1bfb08024ea7d0b3ff85acc [diff] |
Update base::expected using current C++ spec The current base::expected is based on p0323r7. Fix bugs: * Make the unexpected<E> from Err constructor explicit. This constructor is explicit even in p0323r7. Allowing implicit conversions of any type to unexpected<E> is hazardous, because it could turn an intended successful value into an error value. * In the copy/move expected<T, E> constructors that convert from a different expected<U, G> type, use member initialization syntax, var_(...), rather than assigning to var_ in the body. The value and errors type T and E might not have default constructors, and their copy/move constructors should be called, not their assignment operators. Using assignment operators also broke the U to T and the G to E conversions when it required calling an explicit constructor. * Non-swappable value and error types didn't always work. Previously, expected<void, E> could not be instantiated with a non-swappable E because the member swap function wasn't using SFINAE properly. Previously, it was also not possible to instantiate std::is_swappable_v<expected<T, E>> for non-swappable T or E because the namespace-scope swap function wasn't disabled when the member swap function was disabled. * unexpected::swap was calling std::swap. It should instead use the standard idiom of `using std::swap; swap(...);` so that namespace-scope swap functions are called for user-declared classes. Move towards the current C++ draft at https://eel.is/c++draft: * Remove unexpected<Err> to unexpected<E> conversions where Err != E. Converting an Err error value to E for expected<T, E> now happens only in the expected class's constructors and assignment operators. * Rename unexpected<E>::value to unexpected<E>::error to be consistent with expected<T, E>::error. * Include the special bool-related constraints for wg21.link/LWG3836. Ensure that converting expected<bool, E> to expected<bool, G> works as expected by transferring either the success or the error value. Other changes: * Always be explicit about which std::variant alternative is being initialized or assigned. Avoid ambiguity when a value could be converted to either alternative. * Add static_asserts to prevent invalid T and E types. * Mark everything constexpr and provide reasonable noexcept conditions. * Change the float literals in expected_test.cpp to double literals. The use of float literals breaks this line: exp_double::unexpected_type unexp2 = unexpected(10.5f); This line attempts to implicitly convert unexpected<float> to unexpected<double>, which is now a compile-time error. * Remove the bugprone-forwarding-reference-overload lint lines. clang-tidy recognizes this use of std::enable_if in LLVM 14 and up. Bug: b/175635923 Bug: b/328549318 Test: libbase_test Change-Id: Id886db72c0b0103ff2c570ca650cee6d5c463721
This library is a collection of convenience functions to make common tasks easier and less error-prone.
In this context, “error-prone” covers both “hard to do correctly” and “hard to do with good performance”, but as a general purpose library, libbase's primary focus is on making it easier to do things easily and correctly when a compromise has to be made between “simplest API” on the one hand and “fastest implementation” on the other. Though obviously the ideal is to have both.
The intention is to cover the 80% use cases, not be all things to all users.
If you have a routine that‘s really useful in your project, congratulations. But that doesn’t mean it should be here rather than just in your project.
The question for libbase is “should everyone be doing this?”/“does this make everyone's code cleaner/safer?”. Historically we've considered the bar for inclusion to be “are there at least three unrelated projects that would be cleaned up by doing so”.
If your routine is actually something from a future C++ standard (that isn‘t yet in libc++), or it’s widely used in another library, that helps show that there's precedent. Being able to say “so-and-so has used this API for n years” is a good way to reduce concerns about API choices.
Unlike most Android code, code in libbase has to build for Mac and Windows too.
Code here is also expected to have good test coverage.
By its nature, it‘s difficult to change libbase API. It’s often best to start using your routine just in your project, and let it “graduate” after you're certain that the API is solid.