> On 1 Apr 2018, at 23:13, Frank Heckenbach <f.heckenb...@fh-soft.de> wrote: > > Hans Åberg wrote: > >> An advantage with operators names is avoiding parentheses, but a >> problem is that they are hard to search for, but here, since they >> will always together with the $k, that should not be a problem. >> Candidate names might be operator * & ~ + -. > > As I said, I'm not really fond of (mis)using operators like that. > Of course, you (or anyone else) might disagree and do it like that, > Bison neither encourages nor prevents it. > > My "%define" proposal is an alternative (also completely optional; > if you don't set it, it won't do anything). I think it's a bit > easier to use and more general -- it will apply to all types > (including primitive types, where moving is the same as copying, so > effectively no change for them), whereas you'd have to define the > overloaded operator for each relevant type (and couldn't blindly > define it for all types as it already has a meaning for some of > them). Do you have any objections to my "%define" proposal?
It any future Bison developer that decides what to integrate. Otherwise, I think it is OK to be able to choose wrap around $k, but potentially unsafe to always have implicit std::move without pitfall checks.