For optional, it should already have a hash implementation, and that ought to be chosen first? How is boost.JSON modelling optional types, other than range-like now, and is this boost optional specific, or will std:: optional have issues? I haven't looked really closely at boost JSON in a while. It looked much better than rapidJson and Nlohmann JSON, but very similar to one being maintained and supported internally, so I have not used it anger. New evidence can be a reason to revisit a proposal that had consensus. On Mon, Sep 16, 2024, 07:57 Peter Dimov via Boost <boost@lists.boost.org> wrote:
What sort of changes are you anticipating? Opting out of std::format range formatting was one thing we discovered. Does boost jason have similar
Steve Downey wrote: things
for ranges?
Everything that does automatic range handling will potentially be affected, e.g. hash_value.
Yes, Boost.JSON does this as well (provide a default implementation for range- like things.)
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost