On Wed, Mar 17, 2021 at 1:35 PM Richard Smith <richardsmith@google.com> wrote:
On Wed, Mar 17, 2021 at 10:25 AM Arthur O'Dwyer via SG10 <sg10@lists.isocpp.org> wrote:
At the EWG telecon today, I was convinced that P2266 "Simpler implicit move" 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