C++ Logo

std-proposals

Advanced search

Re: [std-proposals] std::constructor

From: Ville Voutilainen <ville.voutilainen_at_[hidden]>
Date: Sat, 9 Aug 2025 23:04:32 +0300
On Sat, 9 Aug 2025 at 22:30, Jens Maurer via Std-Proposals
<std-proposals_at_[hidden]> wrote:
> On 09.08.25 21:06, Avi Kivity via Std-Proposals wrote:
> > A modern range-based solution would look like
> >
> > ```c++
> > auto result = input
> > | std::views::transform([] (size_t sz) {
> > return std::vector<int>(sz);
> > }
> > | std::ranges::to<std::vector>();
> > ```
> >
> > This is still unsatisfying, as the lambda is not concise.
>
> I disagree. The lambda is nice and readable.
> Also, constructors in particular seem to have
> std::initializer_list overloads occasionally,
> but you can't perfectly-forward initializer lists.
>
> Oh, and I haven't used mem_fn for ages, now that std::ranges
> considers pointer-to-members invocable.

Without getting into whether individual lambdas are concise or not..
it tends to be so that slightly longer pipelines
with multiple lambdas make the pipeline awkward to read. What we then
usually do is apply helper
functions that are less like bags of possibly arbitrary code than
lambdas are, even when those lambdas are short.
And here we have such a helper function that generalizes decently
well, and then we can add that generalized
helper into our standard toolbox, nicely packaged.

However.. ..should we have a function object version of
make_from_tuple somewhere in this bigger picture?

Received on 2025-08-09 20:04:48