Unused elements of structured bind

[Andrew Tomazos]

Now that structured bindings are in the wild, we're frequently seeing an issue in practice, whereby there are unused members of a structured bind that trigger the unused diagnostic:

   auto& [a,b] = f();

   g(a);

   // error: b unused

Clearly one can:

  (void)b;

but it seems awkward.

I suspect this is coming up a lot because very often you want to "destructure" something into its component parts, but only use a subset of those components.  When the similar situation comes up for function parameters, people typically comment out (/*paramname*/) the parameter name, but you can't do that with a structured binding.

Was there any reason why we don't allow blank members of a structured binding, so you can write this:

   auto& [a, /*b*/] = f();

I vaguely remember this coming up during design discussion, but don't quite remember why there was opposition?

[Barry Revzin]

On Tuesday, December 11, 2018 at 3:27:51 AM UTC-6, Andrew Tomazos wrote:

Now that structured bindings are in the wild, we're frequently seeing an issue in practice, whereby there are unused members of a structured bind that trigger the unused diagnostic:

   auto& [a,b] = f();

   g(a);

   // error: b unused

Do you have an example? Neither gcc nor clang emit a warning with -Wall -Wextra on something like:

struct X { int i, j; };
int get(X x) {
    auto& [i, j] = x;
    return i;
}

[Ross Smith]

This problem seems to have been fixed in the compilers now. GCC 7.3 does
warn about the above code (with -Wall), but GCC 8.2 doesn't. However,
GCC 8.2 does warn about other unused variables - if you add a gratuitous
"int k = 42;" to the above (and never use k), you get a warning. The
same thing (no warning about unused structured binding, but a warning
about a "legitimate" unused variable) happens with Clang 5.0, MSVC 2017,
and Xcode 10. So I think we can safely conclude that the compiler
vendors have been aware of this issue for a while now, and it's no
longer a problem.

Ross Smith