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

From: Vinnie Falco (vinnie.falco_at_[hidden])
Date: 2024-10-02 22:50:50

On Mon, Sep 16, 2024 at 8:32 AM Steve Downey via Boost <
boost_at_[hidden]> wrote:

> ...

For what it is worth, I rather like p3168r2 over the alternative. The
design of ranges seems such that it anticipates an open set of library and
user-defined adaptors, and long pipelines containing many small
transformations to achieve a desired result. The `views::maybe` and
`views::nullable` adaptors look very much like in the spirit of the ranges
design: small, focused algorithms to achieve a specific well-defined
purpose.

p3168r2 claims that this:

    // Compute eye colors of 'people'.
    vector<string> eye_colors = people
      | views::transform(&Person::eye_color)
      | views::transform(views::nullable)
      | views::join
      | ranges::to<set>()
      | ranges::to<vector>();

is worse than this:

    // Compute eye colors of 'people'.
    vector<string> eye_colors = people
      | views::transform(&Person::eye_color)
      // no extra wrapping necessary
      | views::join
      | ranges::to<set>()
      | ranges::to<vector>();

I prefer the first one, since the transformation is explicit. p3168r2
suggests that the new syntax is "dramatically more straightforward" which
seems exaggerated to me. It is in fact less straightforward, as now the
reader is expected to know about std::optional's expanded role as a range.

I'm all for simplicity, but when you choose C++ you are opting in to a
certain minimum level of complexity. views::maybe and views::nullable seem
like just the right level of complexity for C++. A rangeful std::optional
does not do much for me.

Thanks