On Fri, Oct 4, 2019 at 12:57 PM Barry Revzin via Lib <lib_at_[hidden]>
wrote:

> On Fri, Oct 4, 2019, 1:51 PM Richard Smith <richardsmith_at_[hidden]>
> wrote:
>
>> On Fri, Oct 4, 2019 at 6:56 AM David Vandevoorde via Lib <
>> lib_at_[hidden]> 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: