On Fri, Jun 30, 2023 at 5:12 AM Harald Achitz via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> Yes, I am concerned about the first case, the second should not be
> effected by _.
>
> (void)f() ; is on the list of not allowed lines, since for security
> reasons, use [[maybe_unused]] and add a comment why. Or, simply handle
> the return value, if it is marked as [[nodiscard]], it is for a reason.
>

It sounds like your current coding style guidelines are misguided. You ban
    [[nodiscard]] int f();
    (void)f();
but you fail to extend that ban to
    [[maybe_unused]] int dummy = f();
This leads to people incorrectly writing the latter when they mean the
former, *purely* in order to get around the ban. With all the bad side
effects that entails:
- the latter extends the lifetime of the return value for the rest of the
scope; that is at least unnecessary and at worst incorrect
- the latter is longer to type
- the latter introduces "noise" in the form of [[maybe_unused]] — normally
we would consider [[maybe_unused]] a code smell and try to eliminate
it, but you've got programmers adding [[maybe_unused]] all over the place
for this reason, so each individual usage needs to be checked and re-checked
- the latter requires inventing new names like `dummy`

That's not at all what you want. What you want is for people to *actually
check the return value of `f`*. So you should put *that* in your coding
guidelines.
Then, if any programmer in your organization actually does want to discard
the result of `f`, they should do it like this:
    (void)f(); // with a comment explaining why
This is easy to grep for, and doesn't have any of the disadvantages above.

You consistently fail to distinguish between
- Here is a semantic, human-level behavior B which our programmers *SHOULD
NOT* engage in;
- Here is a syntactic construct S that corresponds 1:1 to that behavior B.
In our case here, B is "discard the result of a nodiscard function" and S
is "(void)f()".
Our coding style guide must not forbid writing S.
In fact, it must *require* the programmer to write S *exactly when* the
programmer intends B.
That way, we can find all the (undesirable) instances of S, simply by
grepping for B.
If we forbid S, then programmers will simply find novel convoluted ways of
expressing B, such that we lose our ability to find instances of S.
Instances of S will proliferate in the codebase.

>> In order to forbid B, we must require that B is always expressed in
terms of S. <<

–Arthur