On Fri, 30 Aug 2019 at 00:56, Aaron Ballman <aaron@aaronballman.com> wrote:

On Thu, Aug 29, 2019 at 7:49 PM Barry Revzin <barry.revzin@gmail.com> wrote:
>
> We had two changes to [[nodiscard]] in Cologne:
>
> - P1301R4: [[nodiscard("should have a reason")]], for C++20
> - P1771R1: [[nodiscard]] for constructors, as a DR
>
> Currently, I put both under the 201907 block (https://isocpp.org/std/standing-documents/sd-6-sg10-feature-test-recommendations#nodiscard). But that means we have a [retroactive] C++17 feature whose macro has a value two years later. Is that fine? Alternatively, we could invent an earlier value for P1771R1 that's in the C++17 timeline.
>
> Thoughts?

I raised this issue in Core and my understanding of the room was that
this is not a serious problem for implementations. Implementations are
expected to use the new value once they've implemented both features.

But what's the expected usage?

If I want to add a reason to my nodiscard attributes, I can do:

#if __cplusplus > 201703L && __has_cpp_attribute(nodiscard) >= 201907

# define NODISCARD(msg) [[nodiscard(#msg)]]

#elif __has_cpp_attribute(nodiscard)

# define NODISCARD(msg) [[nodiscard]]

#else

# define NODISCARD(msg)

#endif

This will not try to use a reason in C++17 code, even if the compiler supports doing so as an extension.

If we had a separate feature test macro for P1301R4 then I could just test for that, and be able to give a reason whenever the compiler supports it (even in C++11/14/17 code):

#if __cpp_nodiscard_reason >= 201907

# define NODISCARD(msg) [[nodiscard(#msg)]]

#elif __has_cpp_attribute(nodiscard)

# define NODISCARD(msg) [[nodiscard]]

#else

# define NODISCARD(msg)

#endif

So I think it's OK for the __has_cpp_attribute(nodiscard) value to mean that both new features are supported, but *also* adding a __cpp_nodiscard_reason macro might make things easier for users. This assumes that some implementations might choose to allow a nodiscard reason pre-C++20.