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
> <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