This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21 Core Issues List revision 115e. See http://www.open-std.org/jtc1/sc22/wg21/ for the official list.
2024-11-11
[Accepted as a DR at the November, 2023 meeting.]
Subclause 9.12.9 [dcl.attr.unused] paragraph 2 specifies:
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.
Absent from that list are labels, but both gcc and clang accept [[maybe_unused]] on a label, and behave accordingly.
Proposed resolution (approved by CWG 2023-07-14)
Change in 9.12.9 [dcl.attr.unused] as follows:
The attribute-token maybe_unused indicates that a name, label, or entity is possibly intentionally unused. No attribute-argument-clause shall be present.
The attribute may be applied to the declaration of a class,
atypedef-name,avariable (including a structured binding declaration),anon-static data member,afunction,anenumeration, oranenumerator, or to an identifier label (8.2 [stmt.label]).A name or entity declared without the maybe_unused attribute can later be redeclared with the attribute and vice versa. An entity is considered marked after the first declaration that marks it.
Recommended practice: 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 marked maybe_unused, implementations should not emit such a warning unless all of its structured bindings are unused. For a label to which maybe_unused is applied, implementations should not emit a warning that the label is used or unused.
[Example 1:[[maybe_unused]] void f([[maybe_unused]] bool thing1, [[maybe_unused]] bool thing2) { [[maybe_unused]] bool b = thing1 && thing2; assert(b); #ifdef NDEBUG goto x; #endif [[maybe_unused]] x: }Implementations should not warn that b or x is unused, whether or not NDEBUG is defined. — end example]
CWG 2023-07-14
CWG has reviewed and approved the proposed resolution. However, this is a new (albeit small) feature, thus forwarding to EWG via paper issue 1585 for approval.
EWG 2023-11-07
Accept the proposed resolution, forward to CWG for inclusion in C++26.