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

From: Steve Downey (sdowney_at_[hidden])
Date: 2024-09-16 12:12:18

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