Thank you for this verbose reply.

I think the topic was largely handled in the short part of my sentence, (... comment, or, simply handle the return value.)

But we can add that in case a nodiscard value makes ever sense to be ignore, maybe removing that attribute for that function makes sense.

Regards, Harald

On 2023-06-30 15:26, Arthur O'Dwyer wrote:
On Fri, Jun 30, 2023 at 5:12 AM Harald Achitz via Std-Proposals <> 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();
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. <<