On Wed, Mar 17, 2021 at 1:35 PM Richard Smith <richardsmith_at_[hidden]>
wrote:

> On Wed, Mar 17, 2021 at 10:25 AM Arthur O'Dwyer via SG10 <
> sg10_at_[hidden]> wrote:
>
>> At the EWG telecon today, I was convinced that P2266 "Simpler implicit
>> move" <https://isocpp.org/files/papers/P2266R1.html> needs a
>> feature-test macro.
>>
>> My question is, what should this feature-test macro's name be? I asked
>> EWG for suggestions and the answer was "not here, go ask SG10."
>>
>> I propose
>> #define __cpp_simpler_implicit_move [whatever]
>>
>> where my understanding is that `[whatever]` will end up being set to the
>> date of the paper's adoption into the working draft.
>>
>> Ship it? Or does anyone have relevant thoughts on naming?
>>
>
> I think a name with a comparative ("simpler") will age badly. I'd suggest
> we either call this __cpp_implicit_move, or perhaps bump the value
> of __cpp_rvalue_references.
>

My second choice is `__cpp_move_eligible`, since this introduces that term
of art into the standard.
The feature has nothing to do with rvalue references per se.


Since you brought it up: Bumping feature-test-macro values is a new pet
peeve of mine. libc++ has no idea what to do when the value of a
feature-test macro *changes*. Say, it's specified to be 20100101L by
default, or 20160101L if X is implemented, or 20200101L if Y is
implemented. What happens when libc++ has implemented Y but not X? Worse,
what happens if the user is compiling in -std=c++11 mode with
-D_LIBCPP_USE_Y=1 but -D_LIBCPP_USE_X=0?
That's why I'd love to get to a world where it was just "one paper, one
macro," and the mapping between paper names and macro names was somehow
mechanical.

–Arthur