On 4/21/23 00:04, Andrew Tomazos wrote:
> On Thu, Apr 20, 2023 at 4:18 PM Stephan Bergmann <sbergman_at_[hidden]
> <mailto:sbergman_at_[hidden]>> wrote:
>
> "A nice placeholder with no name", making _ variables implicitly
> maybe_unused, would nicely cover at least the guard variable scenario;
> and in general it might be better to let maybe_unused consistently
> affect only the marked entity.)
>
>
> Sorry, what's the "guard variable scenario" ?
>
> You mean like `std::lock_guard` for example?
>
> Such variables have non-trivial destructors, so the implementations will
> not warn that they are unused. They don't need to be marked
> [[maybe_unused]].

Right, I had been confused by the documentation of GCC's
__attribute__((unused)) that Lénárd had brought up at
<https://lists.isocpp.org/std-discussion/2023/04/2159.php>: "When
attached to a type (including a union or a struct), this attribute means
that variables of that type are meant to appear possibly unused. GCC
does not produce a warning for any variables of that type, even if the
variable appears to do nothing. This is often the case with lock or
thread classes, which are usually defined and then not referenced, but
contain constructors and destructors that have nontrivial bookkeeping
functions."
(<https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Common-Type-Attributes.html#index-unused-type-attribute>)

So there appears to be even less appeal to have [[maybe_unused]] on a
class extend to variables of that class type. Or does anybody know an
actual use case where that feature makes sense?