What are the advantages in comparison to a lambda?   -----Ursprüngliche Nachricht----- Von:Mital Ashok via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Mo 25.05.2026 08:06 Betreff:Re: [std-proposals] Perfect forwarding for prvalues / expression templates An:Jens Maurer <jens.maurer_at_[hidden]>; std-proposals_at_[hidden]; CC:Mital Ashok <mital_at_[hidden]>; It could also be seen as an extremely abbriviated syntax for a no-argument lamba (`std::lazy(E)` is similar to `[&] -> decltype(auto) { return E; }`, where [&] tips you off that the expression won't necessarily be evaluated, the naming of std::lazy should as well.  For the function call case, it is part of the proposed features that it might not be evaluated (for replacing assert/log macros), relying on function writers to document how their std::lazy arguments are handled. Though I would think most use cases will just call the std::lazy to forward to another function, so this is not going to be surprising to the caller.  This could be morphed into something closer to 'pass an expression to a function', with syntax like `^{ E }` to make it less surprising but not too much more difficult to use, if the 'E might not be evaluated' is too much of a drawback. On Mon, 25 May 2026, 06:50 Jens Maurer, <jens.maurer_at_[hidden] <mailto:jens.maurer_at_[hidden]> > wrote: I understand the following is not the primary use-case, but would work given the proposed facility: On 5/25/26 07:12, Mital Ashok via Std-Proposals wrote: >     std::lazy<int> x = f(); // f is not called here >     return std::move(x)();  // f is called The second line seems fine in isolation, but the first line appears to change core language expression semantics simply via the presence of a special library type used to specify the type of "x". That's plain horrifying, both on an ergonomics level   g(f())  // is f called here?  maybe and on an effort-for-specification level. Jens -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals