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
