Hi Harald,   what alternative would you suggest? An attribute at the call site? E.g. [[overridediscard]f() or [[forcediscard]]f()   Or a std::discard(f()d) function (template) accepting any parameter type?   Is your argument that you  - like a better recommended way to do it like the stated attributes above (working in addition) or  - is your argument that  auto _ = f()  or  (void)f()  should not ignore [[nodiscard]] return values (to definitely prescribe a different way)?   It should probably still be possible to propose other additional ways, e.g. the attributes or std::discard above. Or deprecate the (void)f() case. (Although there would be huge old code bases) But I think  auto _ = f()  is a quite fundamental intentional usage of the underscore in the new proposal.   Sebastian   -----Ursprüngliche Nachricht----- Von:Harald Achitz via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Do 29.06.2023 09:23 Betreff:Re: [std-proposals] Dummy names for dummy objects An:std-proposals_at_[hidden]; CC:Harald Achitz <harald_at_[hidden]>; 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]]  On 2023-06-16 14:25, Chris Ryan via Std-Proposals wrote: P2169 has been actively discussed (yesterday & today, literally minutes ago) and bouncing back & forth between EWG(evolution) & CWG(core) adjusting the usage under special cases.  Things are looking good.  It is potentially likely (no guarantees) that _ (an underscore) will be an unnamed placeholder in C++26 usable in many/most places you would normally have an identifier including structured bindings.   Chiris++; On Sat, Jun 10, 2023 at 5:34 PM Sebastian Wittmeier via Std-Proposals <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]> > wrote: See P2169 A Nice Placeholder With No Name   https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2169r3.pdf https://github.com/cplusplus/papers/issues/878   -----Ursprüngliche Nachricht----- Von: Frederick Virchanza Gotham via Std-Proposals <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]> > Gesendet: Sa 10.06.2023 16:27 Betreff: [std-proposals] Dummy names for dummy objects An: std-proposals <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]> >; CC: Frederick Virchanza Gotham <cauldwell.thomas_at_[hidden] <mailto:cauldwell.thomas_at_[hidden]> >; Sometimes I have code like this: void Func(void) {    OnScopeExit dummy( [](){ ::close(global_fd); } );    // Do more stuff here } If I later amend this function so that further down there's another 'OnScopeExit', then I have to name the second one "dummy1", and the third one "dummy2" and so on. For the sake of making it easier to patch source files, I propose that we can give an object a dummy name as follows: void Func(void) {    OnScopeExit __dummy( [](){ /* Do Something */ } );    // Do more stuff here    OnScopeExit __dummy( [](){ /* Do Something */ } );    // Do more stuff here    OnScopeExit __dummy( [](){ /* Do Something */ } ); } These objects don't have a name clash. If you try to access an object by the name '__dummy', it accesses the most recently defined dummy object: void Func(void) {    OnScopeExit __dummy( [](){ /* Do Something */ } );    // Do more stuff here    _dummy.SomeMethod();   // refers to the object defined 3 lines above    OnScopeExit __dummy( [](){ /* Do Something */ } );    // Do more stuff here    _dummy.SomeMethod();   // refers to the object defined 3 lines above    OnScopeExit __dummy( [](){ /* Do Something */ } ); } -- Std-Proposals mailing list Std-Proposals_at_[hidden] <mailto:Std-Proposals_at_[hidden]> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals -- Std-Proposals mailing list Std-Proposals_at_[hidden] <mailto:Std-Proposals_at_[hidden]> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals