Re: RFC: api.value.automove

[Frank Heckenbach]

Akim Demaille wrote:

> This is not mature:
> 
> - the testsuite fails, because the expected result changes whether
>   std::move is supported or not

For types like std::string I think it's unspecified, even in C++17,
in which state std::move leaves them (as long as it's a valid
state), so it's hard to test. For std::unique_ptr, OTOH, it's
guaranteed that it leaves it as nullptr. Can you use this in the
tests?

To run the testsuite under pre-C++11, I think you basically have to
disable those tests, either skip them outright, or turn them into
dummies with some conditionals. Or, as you suggest below, fail on
this directive pre-C++11 and let the testsuite check for this
failure.

> - is the name right?  api.value.automove
>   I chose something that fit in the current 'hierarchy':

OK for me.

> - should we expose YY_MOVE, which is std::move in C++11+ and nothing
>   otherwise, or just expose std::move and claim users should not use
>   this feature with pre-11?  It does work with pre-11, of course.

I don't see a real need (but might be wrong). I think those who use
C++11+ know it and will use std::move themselves when necessary.
Writing code for pre-/and post-C++11 (and actually using move
semantics in the latter) would seem rather unusual (and a testing
nightmare) to me. A code generator like Bison is in a special place
here.

> - should we not use YY_MOVE and just use std::move instead?  In which
>   case the parser _must_ be compiled in C++11+.

I don't see a problem with it. Again, you know when you use C++11+,
and if you convert your code from pre- to post-, that's actually the
logical time to add this directive, rather then preemptively.

> +Let occurrences of semantic values of the right-hand sides of a rule be
> +implicitly turned in rvalues.

I'm not a native speaker, but I'd have written "turned to" ...

Regards,
Frank