On Sat, 2025-08-09 at 23:04 +0300, Ville Voutilainen via Std-Proposals
wrote:
> 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?


With p3312:

    std::bind_front(&std::apply, &T::T)