On Fri, Oct 4, 2019 at 12:57 PM Barry Revzin via Lib <[email protected]> wrote:
> On Fri, Oct 4, 2019, 1:51 PM Richard Smith <[email protected]> > wrote: > >> On Fri, Oct 4, 2019 at 6:56 AM David Vandevoorde via Lib < >> [email protected]> wrote: >> >>> __cpp_lib_remove_cvref : does this need a macro? It seems like code >>> wishing to support old compilers could define it themselves or >>> unconditionally use remove_reference + remove_cv (I think this fails the >>> "you lose nothing by always behaving like the feature is not present" test, >>> unless I've overlooked a use case). >>> >> > I wasn't sure about the traits. This one seems easily implantable (and the > next two), so maybe not. > An implementation has access to tools that are not available in C++, and so can implement traits more efficiently than can a user. This: namespace stuff { #ifdef __cpp_lib_remove_cvref using std::remove_cvref_t; #else // ... implement remove_cvref_t here ... #endif } is more compile-time efficient on MSVC (were we to define __cpp_lib_remove_cvref, that is) than anything you can write for "implement remove_cvref_t here". Is that sufficient motivation to have feature-test macros even for traits that are easily implemented by hand? For __cpp_nodiscard_reason: I'm opposed to adding this macro in isolation. >> Either we need to accept that version numbers for feature test macros don't >> work (the magic numbers are too magical) and completely rethink our >> approach, or we do not have adequate rationale for this. >> > > Understood. > So, we're saying that __cpp_nodiscard_reason must have a reason? :trollface:
_______________________________________________ Features mailing list [email protected] http://www.open-std.org/mailman/listinfo/features
