C++ Logo

std-proposals

Advanced search

Re: Allow maybe_unused for lambda captures?

From: Arthur O'Dwyer <arthur.j.odwyer_at_[hidden]>
Date: Sun, 15 Dec 2019 13:00:46 -0500
On Sun, Dec 15, 2019 at 11:32 AM Markus Dreseler via Std-Proposals <
std-proposals_at_[hidden]> wrote:

>
> I wonder if it might make sense to [...] allow maybe_unused for lambda
> captures.
>
> The motivation for this can be seen in the following code, where `foo`
> increments `a` depending on the template parameter:
>
> #include <iostream>
> #include <type_traits>
>
> template <bool Enable>
> int foo() {
> int a = 0;
> [&a]() {
> if constexpr (Enable) {
> ++a;
> }
> }();
> return a;
> }
>
> int main() {
> std::cout << foo<true>() << std::endl; // prints 1
> std::cout << foo<false>() << std::endl; // prints 0
> }
>
> As the `foo<false>` instantiation disables the `++a` part, clang
> currently emits a warning:
>
> capture.cpp:7:5: warning: lambda capture 'a' is not used
> [-Wunused-lambda-capture]
> [&a]() {
> ^
>

This is a bug in Clang trunk. A use inside a discarded statement should
suppress -Wunused-lambda-capture exactly as it suppresses -Wunused-variable:

// https://godbolt.org/z/XV-svx
void foo() { int a = 1; if constexpr (E) { throw a; } } // OK
auto bar = [a=1]{ if constexpr (E) { throw a; } }; // WARNING

https://bugs.llvm.org/show_bug.cgi?id=35450

The [[maybe_unused]] attribute shouldn't be used to indicate "this variable
is maybe-used depending on which template instantiation I'm in." The
compiler is perfectly capable of detecting templates on its own.
 [[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.
So what we have here is a use inside a template, that Clang fails to detect
and suppress. That's just a straight-up Clang bug. And someone else has
already noticed and filed it.

HTH,
–Arthur

Received on 2019-12-15 12:03:23