If this is more a topic of tooling, and not for the standard, then that's how it is and it is an answer with which I can work.

Even if I wish and would prefer such situations would be handled by the standard.

Thank you.

Now let's hope that tools can and will catch up on that :-)

Regards, Harald

On 2023-06-30 13:12, Sebastian Wittmeier via Std-Proposals wrote:
AW: [std-proposals] Dummy names for dummy objects

If this is an issue, why cannot some compiler implementations or static analyzers optionally warn, if 'auto _ =' is combined with a [[nodiscard]] returned value?

The standard does/would not prohibit those warnings.


-----Ursprüngliche Nachricht-----
Von: Harald Achitz via Std-Proposals <std-proposals@lists.isocpp.org>
Gesendet: Fr 30.06.2023 11:12
Betreff: Re: [std-proposals] Dummy names for dummy objects
An: std-proposals@lists.isocpp.org;
CC: Harald Achitz <harald@swedencpp.se>;
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.

if auto _ = f(); becomes an alternative to (void)f(); it will land on
the forbidden list in some code bases, and a very useful feature , to
handle the second case where you just want the destructor run, is not

And I think this can be a problem. I am aware that this will not effect
all code bases, but there will be some.

Regards, Harald

On 2023-06-29 17:01, Phil Endecott via Std-Proposals wrote:
> Harald Achitz wrote:
>> Is the discussion about `auto _ = f()` actually done?
>> Just asking since I still think it's a bad idea to allow that as a
>> short form to ignore return values for functions marked as [[nodiscard]]
> It seems to me that we are using [[nodiscard]] for two things. Sometimes
> the caller is expected to actually inspect the function return value;
> examples are functions that return success/error indications that should
> be checked, and functions where the user might be confused about whether
> it returns a result or modifies an in-out parameter.
> In other cases, the returned type is something with a non-trivial
> destructor
> and the requirement is only that it continues to exist to the end of
> the scope,
> rather than being discarded immediately; the obvious example is locks.
> This
> is less strict.
> Perhaps we really need two different attributes for the two cases?
> Regards, Phil.
Std-Proposals mailing list