On Fri, Aug 30, 2019 at 10:00 AM Jonathan Wakely <cxx_at_[hidden]> wrote:

>
>
> On Fri, 30 Aug 2019 at 00:56, Aaron Ballman <aaron_at_[hidden]>
> wrote:
>
>> On Thu, Aug 29, 2019 at 7:49 PM Barry Revzin <barry.revzin_at_[hidden]>
>> 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.
>

Having to check both seems unfortunate.


>
> 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.
>

For what it's worth, Jon Caves had said that he'd received a user complaint
about not having a specific macro for nodiscard w/reason and having to rely
on the two different values instead.

Do we have any other examples in this vein?