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]> 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
>