You have a point.

But for non-generic lambdas, there should be no additional capture. Such as:

const int n = 1;
[=] {int arr[n];};


On Sun, Sep 25, 2022 at 11:19 PM Edward Catmur <ecatmur_at_[hidden]>
wrote:

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