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

From: Peter Dimov (pdimov_at_[hidden])
Date: 2024-09-16 12:18:44

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

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 <boost_at_[hidden]
> <mailto:boost_at_[hidden]> > 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
>