On Sun, 25 Sept 2022 at 15:22, Edward Catmur <ecatmur_at_[hidden]> 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_at_[hidden]> wrote:
>
>> P0588R0 <https://wg21.link/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_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
>