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@lists.isocpp.org>
Gesendet: Do 29.06.2023 09:23
Betreff: Re: [std-proposals] Dummy names for dummy objects
An: std-proposals@lists.isocpp.org;
CC: Harald Achitz <harald@swedencpp.se>;

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@lists.isocpp.org> 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@lists.isocpp.org>
Gesendet: Sa 10.06.2023 16:27
Betreff: [std-proposals] Dummy names for dummy objects
An: std-proposals <std-proposals@lists.isocpp.org>;
CC: Frederick Virchanza Gotham <cauldwell.thomas@gmail.com>;
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@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals

--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals

-- 
 Std-Proposals mailing list
 Std-Proposals@lists.isocpp.org
 https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals