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