Re: [boost] [optional] Feedback on the range interface for Boost.Optional

Steve Downey wrote:

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?

What Boost.JSON does now is documented in the table here https://www.boost.org/doc/libs/1_86_0/libs/json/doc/html/json/conversion.htm... and it currently checks is_sequence_like before is_optional_like, so a type that matches both would be treated as a sequence.

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 mailto:boost@lists.boost.org > wrote:

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