While I am not 100% convinced of [[maybe_unused]] myself, it seems to be the canonical way of handling these situations. Allowing it for lambda captures feels more consistent to me, but I wonder if that justifies making the syntax rule more complex.

As there were no other answers, this does not seem to be a hot issue. Any more thoughts on that?

Best
Markus

On Sun, Dec 15, 2019 at 1:51 PM Markus Dreseler via Std-Proposals <std-proposals@lists.isocpp.org> wrote:

Got it, thank you for the link to the clang bug.

 > [[maybe_unused]] should be used when the use is either completely
absent, or effectively absent because it's used inside a macro that
might be conditionally defined otherwise, or inside an #ifdef block that
was compiled out, or inside an #include file whose contents are
platform-dependent.

If I understand you correctly, this would apply to the following
example. Could you please give your thoughts on this one:

     #include <cassert>
     void foo(int a) {
       [&a](){
         assert(a == 3);
       }();
       // actually do something with a
     }

https://godbolt.org/z/udHag8

Ah, yes, that would be a place where [[maybe_unused]] might apply.

However, for now, you can easily write

    (void)a;

to suppress the warning: https://godbolt.org/z/7ZHSYz

That's less cluttering to the code (thus easier to read and maintain), and also works in existing compilers (thus easier to deploy).

"Yeah, but using this logic, isn't [[maybe_unused]] completely redundant and unnecessary and should never have been standardized?"

AFAIK, yes.

–Arthur