Hi Giuseppe, I think (according to the original post on April 14th) it is about calling a lambda with captures in an indirect or delayed way. The captures should be serialized into a byte stream and later on the lambda is recreated with those captures and called. As the lambda perhaps can come from existing code, it cannot be changed into a function object.   My reaction was that the serialization of general (not trivially-copyable) objects is not solved for C++ in general.   Perhaps the solution of the original problem would be to demand certain captures of certain data types to lead to trivially-copyable lambdas instead of making its properties implementation defined?   Then  - there is no problem with [x] capture,  - no constructor is needed, just memcpy   Best, Sebastian   -----Ursprüngliche Nachricht----- Von:Giuseppe D‘Angelo via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Do 20.04.2023 17:13 Betreff:Re: [std-proposals] Lambda type not isolated within function Anlage:untitled An:std-proposals_at_[hidden]; CC:Giuseppe D‘Angelo <giuseppe.dangelo_at_[hidden]>; Il 20/04/23 16:35, Frederick Virchanza Gotham via Std-Proposals ha scritto: > > How about allowing the creation of new lambda object (with captures) > by using initialiser braces? How about it? Write a proposal that changes how the closure type looks like, so to allow that kind of list initialization (what kind of initialization precisely should be performed and how?), and be sure to add compelling motivation to it. Because otherwise the natural objection is that _today_ you can simply go from > > auto Func(int const arg) > { >     auto mylambda = [arg](void) -> int >       { >         return arg + 3; >       }; > >     return mylambda; > } to > >  struct { >    int arg; >    auto operator()() const -> int { return arg + 3; } >  } mylambda = { arg }; > >  return mylambda; And then you're good to go. -- Giuseppe D'Angelo -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals