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

From: Steve Downey (sdowney_at_[hidden])
Date: 2024-09-15 14:42:20

The core motivation is not having yet another optional-like in the standard
library. Ranges needs a 0-or-1 range as a primitive for where the filter
algorithm isn't quite the right answer, in particular for range
comprehension desugaring which comes up fairly often by hand.
Having a range type like empty or single, without a bunch of the implicit
conversion operations from the underlying type, was my preference, however
adding the range ops to optional<T> was a reasonable fallback.

And optional not being a container was always a suspect position,
especially after the addition of other fixed size or limited size
containers. Making it a full Cpp17 Container is probably over the top, and
might have confused existing code, but adding the range interface is
minimal.

On the other hand, once we have std::optional<T&> and possibly
optional<T&&>, boost's optional should probably be avoided in codebases
using C++26 or later.

On Sat, Sep 14, 2024 at 7:59 AM Thomas Fowlery via Boost <
boost_at_[hidden]> wrote:

> Every feature should be well motivated by a real use case or a set of use
> cases. I don't find any of the examples in this proposal motivating. In
> fact, this feature seems to encourage bad code, judging by the examples:
> - using transform(f) | join with an optional-returning function f, instead
> of using a simple filter(predicate)
> - materializing optionals when not really necessary (incurs extra
> moves/copies)
> - abusing the range-for loop for unwrapping optionals
>
> Best regards,
> Thomas
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>