On Wed, Mar 17, 2021 at 10:43 AM Arthur O'Dwyer <arthur.j.odwyer@gmail.com> wrote:
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.

I'm not sure that "move eligible" is something that people will associate with this change in the future. That this paper introduces the seems incidental: it's not unreasonable to reformulate the older rules in terms of move eligibility, and that term might go away with later wording changes.

Something that says "implicit move" or "automatic move" or something in that area seems like it would weather the sands of time better.
 
The feature has nothing to do with rvalue references per se.

I suppose that's true; I suggested __cpp_rvalue_references because it's the macro that determines whether we get any implicit moves today, but perhaps that's too weak a connection.
 
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?

The intent is that the higher value implies all the lower values are also implemented. If Y-but-not-X is an anticipated scenario, we shouldn't use the same feature test macro for X and Y. I think we've mostly only bumped feature test macro values after everyone already implemented the lower value (preventing the Y-but-not-X scenario for at least those implementations we're aware of), but I don't think that has always been the case and nor do we have any kind of policy guaranteeing that (that I'm aware of).
 
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?

Generally speaking, our charter does not cover enabling the post-facto subsetting of C++. That's explicitly not what feature-test macros are for; the directional guidance this group has received from the C++ committee was pretty clear about that. (I think libc++ has also been resistant to such subsetting in general, as have various other implementation projects.) __cpp_exceptions and __cpp_rtti are notable exceptions, but it's not within our power to put the genies back in those bottles.

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.

These macros aren't free, and bumping the versions is one way in which we're trying to slow the explosion of macro names.