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