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

From: Neil Groves (neilgroves_at_[hidden])
Date: 2024-09-29 13:41:02

On Mon, 16 Sept 2024 at 12: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.)
>

This is an extremely important point. This change will break real-world
code. I have many cases where I have an overload that is differentiated by
using the std::xxx_range concept. If I understand correctly, having
optional model range will potentially alter overload resolution. This most
likely will lead to compilation errors, but it seems entirely possible to
have silent runtime errors, making the change unforgivable, in my opinion.
The evidence, already, is that library maintainers are having to check to
see if this will break their code. This to me, demonstrates that there is
acceptance by many others that this has the potential to break existing
code.

The design alternative to have a non-member function adapter seems safer,
more extensible and more re-usable. I very rarely want an optional to
behave like a range. I find it hard to imagine this is the typical semantic
most use-cases have in mind for optional.

Making "optional" model any of the xxx_range concepts directly is an
extremely bad idea because it will break code for very little upside
compared to having an explicit call to adapt.

Regards,
Neil Groves