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

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
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals