> On 15 Sep 2018, at 19:15, Frank Heckenbach <[email protected]> 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.
