On Fri, Oct 4, 2019 at 1:29 PM Casey Carter <cartec69@gmail.com> wrote:
On Fri, Oct 4, 2019 at 12:57 PM Barry Revzin via Lib <lib@lists.isocpp.org> wrote:
On Fri, Oct 4, 2019, 1:51 PM Richard Smith <richardsmith@google.com> wrote:
On Fri, Oct 4, 2019 at 6:56 AM David Vandevoorde via Lib <lib@lists.isocpp.org> 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?

Mm, good point. Personally, I find that persuasive. (It'd presumably make even more difference, relatively-speaking, if we had http://www.open-std.org/Jtc1/sc22/wg21/docs/papers/2019/p1715r0.html and the cost of a class template instantiation were no longer a factor.)
 
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: 

(-: