> Use a cast to (void) to suppress nodiscardness.

Will not pass a code review, for reason
[[maybe_unused]] deserves a comment, for reasons, to pass a code review.

If auto _ silences nodiscard warnings, I can guarantee you, it will land on the list of features not to use in some projects, and it will be a point of discussion if / when we move to new standard version.

This can / should not be the indent of that actually very nice feature/idea.

Well, I addressed my concerns about this now the second time, if I am the only one seeing a problem in code maintainability and readability when _ makes nodiscad pointless, than maybe it's not such a concern for people here and not worth to follow up  further

On 2023-06-29 17:02, Arthur O'Dwyer wrote:
On Thu, Jun 29, 2023 at 10:20 AM Harald Achitz via Std-Proposals <std-proposals@lists.isocpp.org> wrote:

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

I think you're misunderstanding the merged proposal and possibly also the status quo.
(I don't particularly care for the merged proposal either, but only because I don't like making `_` into a magic identifier; it's one more thing to teach and I don't think its benefit outweighs that cost. Nonetheless...)
Suppose in C++26 someone writes:
    auto _ = f();
This unambiguously means they want to save `f()`'s value until the end of scope, but that they won't use it for anything otherwise.
"But what if `f` was [[nodiscard]]?"
That's fine. The programmer is using `f`'s value; they're saving it until the end of scope.
"But shouldn't this still be diagnosed? They didn't say [[maybe_unused]]!"
No, that's fine. `_` is unused by definition. If the programmer wanted to get a -Wunused warning, they wouldn't have called the variable `_`.
    auto x = f();  // OK, now we get a -Wunused warning if `x` is never used
"So people will use `auto _ = f()` to conveniently suppress nodiscardness?"
No, people already use
if all they want to do is suppress nodiscardness. They'll keep doing that.
The reason to use
    auto _ = f();
is that you want to save `f()`'s value until the end of scope (i.e. not discard and destroy it immediately). If you just want to discard f()'s value, you wouldn't do that.

In fact, personally I might hope for a compiler warning whenever someone writes
    int _ = f();
(or any trivially destructible type like that), because in that case there's no point to capturing `_` at all. That line of code probably indicates that the programmer doesn't understand the point of capturing `_`, which is to prolong the lifetime of a value whose destruction will have side effects.

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

That is the exact opposite of the point.
    auto lk = my::lock_guard(m);  // my::lock_guard is [[nodiscard]]
compiles today without warning, and has the right behavior, but requires choosing a unique name `lk`.
    auto _ = my::lock_guard(m);  // my::lock_guard is [[nodiscard]]
compiles in C++26 and does not require choosing any unique name, so, it's better.
If the compiler gave a diagnostic on the latter line, then we couldn't write it, and so the entire `_` feature would have no point at all.

> Use a cast to (void) to suppress nodiscardness.
> Use `_` to prolong a lifetime to the end of scope without choosing a unique name.