问题
Functional languages with pattern matching (sometimes?) have the possibility to ignore some bound values, but with C++17 structured bindings there seem to be no way to do that (std::ignore with structured bindings?). The advice is to use a dummy name, but then we'll get warnings about unused variables.
With the latest heads of both clang and gcc, this does the expected thing, which is nice and useful,
[[maybe_unused]] auto x =4 ; // fine, no warning
[[maybe_unused]] auto [a,dummyb,dummyc] = std::tuple<int,int,float>(1,1,1.0f);
but I would also have hoped this would work:
auto [g,[[maybe_unused]]dummyh,[[maybe_unused]]dymmyi] =
std::tuple<int,int,float>(1,1,1.0f);
is there a specific reason attributes can not be used here? (in the standard as well as technically). Neither gcc or clang accepts this.
Edit, collecting the support status: (thanks to godbolt/compiler explorer). It works as expected in (could be earlier also):
- gcc 8.0 trunk (g++ 8.0.0 20171015 experimental)
- clang 4.0.0
- icc 18 (not tested, according to specs)
MSVC 17.3.5 (and the Visual Studio GUI), allows the attribute but it does not work with structured bindings. bug report
回答1:
In the structure bindings paper:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0144r2.pdf
they discuss their reasoning:
3.8 Should there be a way to explicitly ignore components?
The motivation would be to silence compiler warnings about unused names.
We think the answer should be “not yet.” This is not motivated by use cases (silencing compiler warnings is a motivation, but it is not a use case per se), and is best left until we can revisit this in the context of a more general pattern matching proposal where this should fall out as a special case.
Symmetry with std::tie would suggest using something like a std::ignore:
tuple<T1,T2,T3> f(); auto [x, std::ignore, z] = f(); // NOT proposed: ignore second element
However, this feels awkward.
Anticipating pattern matching in the language could suggest a wildcard like _ or *, but since we do not yet have pattern matching it is premature to pick a syntax that we know will be compatible. This is a pure extension that can wait to be considered with pattern matching.
Although this does not explicitly address [[maybe_unused]]
, I assume the reasoning might be the same. Stopping compiler warnings is not a use-case.
回答2:
As a resolution to CWG 2360, the working draft of the standard gained the following wording ([dcl.attr.unused]):
The attribute may be applied to the declaration of a class, a typedef-name, a variable (including a structured binding declaration), a non-static data member, a function, an enumeration, or an enumerator.
For an entity marked
maybe_unused
, implementations should not emit a warning that the entity or its structured bindings (if any) are used or unused. For a structured binding declaration not markedmaybe_unused
, implementations should not emit such a warning unless all of its structured bindings are unused.
Structured binding declarations were previously not explicitly mentioned.
来源:https://stackoverflow.com/questions/41404001/structured-binding-with-maybe-unused