On Sun, 25 Sept 2022 at 15:22, Edward Catmur <ecatmur@googlemail.com> wrote:
What about the `might_use` problem? That wouldn't be solved by your proposed refinement. 

Sorry, realized I'm talking nonsense here.

Still, if I understand correctly, your proposed rule would be that a default capture captures a variable if either (a) it is odr-used, or (b) it is used in evaluated context within a branch of a constexpr if whose condition is dependent on a lambda template parameter. So, for example, in

auto f = [](auto a) {
    int const i = 10;
    auto g = [=] { int arr[i]; };
    if constexpr (sizeof(a) == 1)
        auto h = [=] { int arr[i]; };
};

g would not capture i, but h would. Isn't that liable to be somewhat confusing?

On Sun, 25 Sep 2022, 09:11 blacktea hamburger via Std-Proposals, <std-proposals@lists.isocpp.org> wrote:
P0588R0 contains the rationale explaining why the rules for implicit capture were changed in order to capture some variables that are not going to be odr-used anyway.

However, it makes the rules too simplistic.

For non-generic lambda, the paper says "Note that we propose applying this treatment uniformly to both generic and non-generic lambdas (this is not essential to the proposal, but seems to give a more consistent language rule)." This consistency is useless. It does ease the workload for some language-lawyers, but the impact on the average developers is redundant captures.

For generic lambda, the rules can only apply to expressions in constexpr-if, and the condition of it depends on a generic lambda parameter.

This is enough to solve the problem to be solved in the paper.
--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals