Em dom., 28 de nov. de 2021 às 21:13, Jason McKesson via Std-Proposals <std-proposals@lists.isocpp.org> 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.