[libcxx-dev] Proposal to replace `_LIBCPP_NODISCARD_EXT` with `[[nodiscard]]`

[Mark de Wever via libcxx-dev]

On Thu, May 13, 2021 at 10:47:11AM -0700, Christopher Di Bella via libcxx-dev wrote:
> Hi folks,
> 
> There's been a lot of requests for `[[nodiscard]]` to be replaced with `
> _LIBCPP_NODISCARD_EXT` in recent reviews where the standard doesn't
> explicitly declare an entity with the nodiscard attribute. After some
> investigation, I've discovered that this feature is confusing and
> error-prone. `_LIBCPP_NODISCARD_EXT` is opt-in, which requires users to
> know about its existence (I certainly didn't until reviewers started asking
> for it, and even then, didn't expect it to be opt-in), and then has three
> ways to opt out of its use: `_LIBCPP_DISABLE_NODISCARD_EXT` (global), `
> -Wno-unused-result` (global), and cast to `void` (local).

Looking at the patch introducing the feature it seems this comment is
the reason to make it an opt-in https://reviews.llvm.org/D45179#1077048

> Since It's unclear why we want so many toggle options for this feature, this
> attribute doesn't change a user's program
> <http://eel.is/c++draft/dcl.attr.nodiscard>, and users already have
> two compiler-based
> opt-out mechanisms <https://godbolt.org/z/hsWo1v5W9> for all supported
> compilers and C++ standards, I think it's reasonable to remove this
> attribute in favour of the easier-to-use attribute itself.

As a standard library vendor I think we should be careful against
breaking the code of our users when they upgrade to a newer version of
Clang and libc++. So I'm against just making all extensions available
unconditionally. Even if we think there's no good reason to discard the
return of certain functions somebody might have a valid reason. If we
make this change the user either needs to disable the `nodiscard`
diagnostics globally or adjust their code.

If we want to make this extension available unconditionally I think we
should first change the switch from opt-in to opt-out and document these
changes in the release notes. At a later stage we can remove the opt-out.
That way we can get feedback on the extension and we might note we've
been too liberal with adding `nodiscard`s.

I would like to know what the other vendors do in this area. If
libstdc++ and MSVC STL also have additional `nodiscard`s it would be
nice to align with them. Then, of course, it would  be nice if there
were a paper to make these extensions part of the Standard.

Cheers,
Mark de Wever