On Sat, Jun 21, 2025 at 9:07 PM JJ Marr via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> For function parameters that are slow to copy, we have const references. For lambda captures that are slow to copy, we do not have an easy equivalent.
>
> The easiest way to do this is:
>
> ```cpp
> #import <functional>
> #import <utility>
> int var;
> [newVar = std::cref(var)](){
> // body
> };
>
> [&newVar = std::as_const(var)](){
> // body
> };
> ```
>
> This requires importing the functional (for std::cref) or utility (for std::as_const) headers. It also requires the creation of a new identifier, possibly with a different name to avoid variable shadowing warnings.
>
> We should be able to `const`-qualify a lambda capture. For captures by-value on a non-mutable lambda, this would have no effect because value-captures cannot be modified. For reference captures or a mutable lambda, this would have the same behaviour as `const` on any other identifier (cannot modify/call non-const members/etc). A possible syntax would be:
>
> ```cpp
> [const &var](){
> // body
> };
> ```
>
> Open questions:
> * Should we allow for other/arbitrary qualifiers? i.e. volatile?
> * Can we apply qualifiers to a default capture? e.g.:
>
> ```cpp
> [const &](){
> // body
> };
> ```
>
> Appreciate feedback on whether this is a good enough idea to turn into a proposal.

For all intents and purposes, a lambda that captures local variables
by reference is a part of the function it is within. So why does it
need to capture the variable as `const`? If the object wasn't already
`const`, why does the lambda need non-modifying access to it? The rest
of the function could modify it, so why does there need to be special
syntax to prevent one part of that function from modifying it?