Em dom., 28 de nov. de 2021 às 21:13, Jason McKesson via Std-Proposals <
std-proposals_at_[hidden]> escreveu:

>
> And yet:
>
> auto [val1, val2, val3] = std::tuple{expr1, expr2, expr3};
>
>

I'm aware of C++ initialization, but you implied a dichotomy, that "[] is
for decomposition and {} is used for composition", but lambdas does that
in the capture right ? A capture is different from a "list of values'', you
understand that as "composition" or "decomposition" case ? I'm proposing
the use of a "naked capture";

That's merely piggybacking on an implementation detail. It makes sense
>
only from the perspective of whatever already exists that looks
> vaguely like the thing you're trying to make work.
>

I´m biased here ( would not be the first time some idea or syntax endup
constrained by implementation detail ), "piggybacking" is a good term,
although it's not for lack of thinking, it's the opposite, I was trying to
do minimal changes in the language, and big changes, that's a no-go in the
majority of cases.

You said nothing about a syntax to declare a function that takes named
> parameters.


I did, I showed a wrapper rect in the first email. and says "sort of" named
parameters.

template<typename Params>
> auto func(Params params)
> {
> return params.param1 + params.param2;
> }
> ```
>
> That's not feasible. Nor does it solve the forwarding problem with
> regard to named, variadic parameters.
>

Maybe feasable, maybe not, since you need to provide a wrapper, the same
way ranges needed a lot of adaptation to be used with algorithms, but I
would not try to constrain the imagination of c++ community.
Althow, with reflection, that will be feasible to do automatically.


Cleiton