Re: Automatially move from $n (was: C++11 move semantics)

[Hans Åberg]

> On 15 Sep 2018, at 19:15, Frank Heckenbach <address@hidden> wrote:
> 
> Akim Demaille wrote:
> 
>>> By default it's empty, so it's like before, but one can e.g. add
>>> 
>>> %define api.rhs.access {std::move}
>> 
>> I would like to have your opinion on this, a few months after
>> having practiced the idea.  It looks great, but some ideas look
>> great first, and them show some limitations.
>> 
>> Would you recommend that we really import this into Bison?
> 
> I would. My grammar file is much more readable with it, as it saves
> me multiple std::move calls in most rules.
> 
> Of course, there's a danger of using a moved-from value. When I
> introduces it, I had to check my grammars for multiple uses of the
> same value which I did to a first approximation with a regex search
> (something like "(\$[0-9]+).*\1"), then checked the few remaining
> cases manually (but my grammar rules are rather simple; most of the
> actual work is done in external functions, often just make_unique<>,
> sometimes self-written ones).
> 
> As I wrote, if Bison could detect multiple uses and warn, that would
> be great, but I didn't look into it as I didn't want to patch Bison
> itself.
> 
> Another syntax (just for the sake of example "#1" for moving, while
> keeping "$1" as is) might be an idea, but is still dangerous if one
> uses $1 after #1, so probably not worth it.
> 
> So, lacking other ideas, I'd stay with api.rhs.access, which was
> easy to implement and does the job for me. I certainly don't want to
> put std::move everywhere in my grammar. -- In fact, if I'd
> ultimately have to, I'd make make up something like "#1" and
> preprocess my grammar with sed before feeding it to Bison, to keep
> it readable. Seeing as Bison does lots of processing of the source
> anyway, this would seem overly complicated and bizarre to me.

One idea might be to wrap the actions in inlines, and use return instead, as 
C++ can recognize r-values in such situations.