On 4/02/2023 07:14, Robert Ramey wrote:
1. The user has to know that the integration exists and explicitly #include an additional header file (e.g. boost/serialization/optional.hpp) when they're using both together.
or ... boost/optional/serialization.hpp ?
Perhaps, though as I said I find the "optional is more fundamental" argument more compelling, so by that logic the compatibility code should be in serialization and not optional. Also, boost/serialization/optional.hpp already does exist, and boost/optional/serialization.hpp does not. Though having both header files exist (with one merely a redirect to the canonical one) could be an interesting choice, to allow the user to not have to think about which one is more fundamental. (Though if one file exists and one does not, that becomes obvious fairly quickly.) One downside of the current serialization implementation is that (as far as I can see) it *only* supports boost::optional and not std::optional, and the "obvious" header name (boost/serialization/optional.hpp) is already taken. Were it to extend support for std::optional in the future, how should that look? Just detect C++17 and then assume you want it automatically? Try to auto-detect a previous #include <optional>? Assume including boost/serialization/optional.hpp means you want both? Introduce boost/serialization/std_optional.hpp? All of these choices have pros and cons. Another variant might be mixing several of these, by renaming current optional.hpp to boost_optional.hpp, adding std_optional.hpp, and then a new optional.hpp that includes one, the other, or both based on C++17 support (or detecting prior include of Boost.Optional), though there are several caveats there too.