On Wed, Mar 17, 2021 at 10:43 AM Arthur O'Dwyer <arthur.j.odwyer_at_[hidden]>
wrote:

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

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.