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 16.12.19 00:35, Arthur O'Dwyer wrote:
> On Sun, Dec 15, 2019 at 1:51 PM Markus Dreseler via Std-Proposals
> <std-proposals_at_[hidden]
> <mailto:std-proposals_at_[hidden]>> 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