Compilers can make optimizations, and behavior can be non-standard. So, is
it enough just by testing on compilers?

On Sat, Oct 1, 2022 at 9:56 PM Arthur O'Dwyer <arthur.j.odwyer_at_[hidden]>
wrote:

> On Sat, Oct 1, 2022 at 8:42 AM blacktea hamburger via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>>
>> But for non-generic lambdas, there should be no additional capture. Such
>> as:
>>
>> const int n = 1;
>> [=] {int arr[n];};
>>
>>
> This lambda doesn't capture anything. `n` is not being odr-used here. You
> can verify this using `sizeof`:
> const int n = 1;
> auto lam = [=] { int arr[n]; };
> static_assert(sizeof(lam) == 1);
>
> The only time a capture is needed is when it must be materialized — i.e.
> when it is odr-used such that a definition is required — i.e. when
> its address is taken such that it needs a memory address at runtime.
> Compare:
>
> void f(int);
> auto flam = [=] { f(n); };
> static_assert(sizeof(flam) == 1);
>
> void g(const int&);
> auto glam = [=] { g(n); };
> static_assert(sizeof(glam) == 4);
>
> Before asking for a problem to be fixed, it is always good to *try your
> code on a compiler* and see if there is a problem at all. You can't
> understand C++ in a vacuum just by reading PDFs; you have to fiddle around
> with the language in practice to find out whether
> the-things-you-think-are-problems-on-paper are actually problems, or if
> you've just misunderstood what the paper was saying.
>
> –Arthur
>
>
>
>> 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
>>>>>
>>>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
>