Hi,


my concern is that auto _ = f();


* will be abused by lazy developers to not care about nodiscard return
values, instead of a clear syntax that makes it obvious that for any
reason a nodiscard return value is ignored

Today, there is a more verbose syntax required, and that makes it more
readable to see what is going on in code reviews and when reading the code.


* makes it impossible to catch unhandled return values if for any reason
nodiscard gets added to a function and _ is already in use


My suggestion would simply be, if a function is nodiscard, the _ to
ignore it's returnvalue should not compile (keep the warning).

Or will the warning we have today will be preserved when _ is used ? In
that case, my concern is not valid.


If this is technically possible, I do not know.

But I am sure its a win for code quality, because there will be that
one case, where a return value gets overseen because of _

And this might be a reason for some code bases to not allow the feature
at all. (that will happen, I know such projects, for exactly this reason)


Regards, Harald



On 2023-06-29 14:45, Sebastian Wittmeier via Std-Proposals wrote:
> AW: [std-proposals] Dummy names for dummy objects
>
> 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]> 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]>
>> *Gesendet:* Sa 10.06.2023 16:27
>> *Betreff:* [std-proposals] Dummy names for dummy objects
>> *An:* std-proposals <std-proposals_at_[hidden]>;
>> *CC:* Frederick Virchanza Gotham
>> <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]
>> 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
>>
>>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
>
>