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

[Akim Demaille]

> Le 15 sept. 2018 à 19:15, Frank Heckenbach <address@hidden> a écrit :
> 
> Akim Demaille wrote:
> 
>> 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.

Great, thanks for the input!

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

Agreed.  But then, the syntax you choose, is a little weird:
the syntax is quite generic (we apply some treatment to $k,
which could be for instance printing its value (stupid, but
why not)), but the warning would be really specific for move.

Shouldn’t we go for something like %define api.value.move,
or api.rhs.move, or api.rhs.rvalue, etc.  I mean, as a Boolean
value, not a generic placeholder.

First let’s decide what is the feature, then we’ll find the
proper name :)

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

I don’t think Bison’s should have more special characters.
#define M std::move can make it light enough, but I agree
with adding automove.