On Fri, Oct 4, 2019 at 1:29 PM Casey Carter <cartec69_at_[hidden]> wrote:

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

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

(-: