On Wed, Mar 17, 2021 at 1:35 PM Richard Smith <[email protected]> wrote:
> On Wed, Mar 17, 2021 at 10:25 AM Arthur O'Dwyer via SG10 < > [email protected]> 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
-- SG10 mailing list [email protected] https://lists.isocpp.org/mailman/listinfo.cgi/sg10
