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
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