C++ Logo

std-proposals

Advanced search

Re: [std-proposals] Dummy names for dummy objects

From: Sebastian Wittmeier <wittmeier_at_[hidden]>
Date: Fri, 30 Jun 2023 13:12:19 +0200
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  

Received on 2023-06-30 11:12:21