Re: RFC: api.value.automove

[Akim Demaille]

> Le 20 sept. 2018 à 23:44, Frank Heckenbach <address@hidden> a écrit :
> 
> 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.

Bummer, you are right.  I guess the cheapest is to leave the
content in the case of the small string optimization, and
actually move it otherwise.  I can see why it’s left unspecified.

> For std::unique_ptr, OTOH, it's
> guaranteed that it leaves it as nullptr. Can you use this in the
> tests?

I was looking for a test that works with legacy and modern C++.
(But not expecting the same traces, of course.  Just the same
outcome).


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

Yes, exactly.  It’s like when a C++98 project is compiled with
a C++11 compiler: your program is faster ‘for free’, thanks to
plenty of implicit moves and a library that is ready to embrace
them (e.g., all the operations on vectors).

That’s why I was aiming first at not requiring modern C++ when
using automove: this way a project that does not require C++11
can still compile in C++98, yet benefit from the move-speedup
if it turns out that the underlying compiler supports it.

Hum.  It seems that I’m convincing myself that I should accept
legacy C++ with automove :/.  The question would then be: is
there a catch I did not see?


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

Good catch, thanks!