On Fri, Aug 30, 2019 at 10:00 AM Jonathan Wakely <[email protected]> wrote:
> > > On Fri, 30 Aug 2019 at 00:56, Aaron Ballman <[email protected]> > wrote: > >> On Thu, Aug 29, 2019 at 7:49 PM Barry Revzin <[email protected]> >> 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?
_______________________________________________ Features mailing list [email protected] http://www.open-std.org/mailman/listinfo/features
