On Sat, Oct 5, 2024, 10:42 Andrzej Krzemienski
czw., 3 paź 2024 o 00:51 Vinnie Falco
napisał(a): On Mon, Sep 16, 2024 at 8:32 AM Steve Downey via Boost < boost@lists.boost.org> 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.
Ok, I now have a paper to revert the range interface from Optional: https://isocpp.org/files/papers/D3415R0.html
Regards, &rzej;
I think when you say
Whether [P2988R7]
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p2988r7.pdf should
be added instead, we have no strong opinion.
You mean P1255, view maybe? P2988 is optional