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_at_[hidden]>
> *Gesendet:* Fr 30.06.2023 11:12
> *Betreff:* Re: [std-proposals] Dummy names for dummy objects
> *An:* std-proposals_at_[hidden];
> *CC:* Harald Achitz <harald_at_[hidden]>;
> 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_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
>