https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #77 from Andrew Church <achurch+gcc at achurch dot org> ---
(In reply to Segher Boessenkool from comment #72)
> if (foo()) {
> /* The return value of foo can be ignored here because X and Y. */
> }
This is just another idiom, with "if(){}" replacing "(void)"; it does not
directly indicate that the value is unused, as a hypothetical [[discard]] would
do. I would even argue that it is worse because (as Zdenek points out) it adds
a branch which would either need to be tested, potentially requiring additional
failure injection logic to trigger the failing case, or documented as not
needing to be covered by a test.
In general, I would consider any code structure with no behavioral effect but a
semantic side-effect (including casting to void, assigning to an unused
variable, or testing in a conditional with an empty block) a code smell, and
would prefer an explicit [[discard]] to make the intent clear. Given that we
have no [[discard]], I still hold that cast-to-void is the best existing option
due both to conciseness and to widespread recognition of its intent.
There's also an argument to be made that allowing the warning to be bypassed
with if(){} or assignment to an unused variable is weakening the original
intent behind WUR, as Jakub mentions.
(In reply to Jakub Jelinek from comment #76)
> (void) casts not quieting the warning was an intentional request when the
> warning has been added, I really don't think it is a good idea to change
> that.
This is why I initially suggested a compiler option (-Wunused-result=strict) to
select the behavior. It could of course be coded in reverse, defaulting to the
current behavior and having e.g. -Wunused-result=lax to inhibit WUR warnings.
The fundamental problem with the request behind this feature (in particular,
with the fact that the request comes from a library author) is that the end
user of the compiler is the library user, not the library author, and if the
end user considers the warnings useless, they will find one or another way
around them, however much collateral damage (in the form of missed errors) that
may cause. Given that, I think it's reasonable to offer a middle-ground option
that lets the end user reject the library author's original intent of forcing
return value usage but retain the ability to check for accidentally unused
return values.
