Those relying on container_adapter<optional<T>> and the builder's
register_container<optional<T>>() behavior will have to switch to the
more explicit optional_adapter<optional<T>> and the related builder's
register_optional<optional<T>>. This behavior is safer than relying on
the inclusion of serialization_optional.hpp for users to access the
partial specialization and make their code work.
Since the specialization lived in serialization_optional.hpp, anyone
relying on the old behavior will get a reasonably-accessable compilation
error during upgrade. Those deleting their
#include <jsonv/serialization_optional.hpp> without further thought
will get a less reasonable compilation error in the internals of
container_adapter.
Those relying on
container_adapter<optional<T>>
and the builder'sregister_container<optional<T>>()
behavior will have to switch to the more explicitoptional_adapter<optional<T>>
and the related builder'sregister_optional<optional<T>>
. This behavior is safer than relying on the inclusion ofserialization_optional.hpp
for users to access the partial specialization and make their code work.Since the specialization lived in
serialization_optional.hpp
, anyone relying on the old behavior will get a reasonably-accessable compilation error during upgrade. Those deleting their#include <jsonv/serialization_optional.hpp>
without further thought will get a less reasonable compilation error in the internals ofcontainer_adapter
.