> On 1 Apr 2018, at 22:32, Frank Heckenbach <[email protected]> wrote: > > Hans Åberg wrote: > >>> If semantic_type doesn't have a "*" operator of its own, this might >>> work (but look confusing). However, I use the variant (so I'd need >>> this function for each alternative, which might be possible to do >>> with templates), but some of my semantic values are (smart) >>> pointers, so "*" is already used (and even if I could somehow >>> override it, it would suggest dereferencing rather than moving). >> >> Alternative unary operators are listed as point 3 at [1]. One can >> overload operator&, but is more confusing than *, as it disables >> taking the address-of. > > Yeah; all existing operators have their meaning, and might apply to > some or all alternatives one might use. C++ doesn't allow defining > new operators (probably for good reasons), and I'm generally wary of > overloading operators for unrelated purposes (don't already like the > stream "<<" and ">>" too much). > >>> Now, if C++ had a dedicated move operator (which would also be >>> useful in other code) ... But (ab)using an existing operator seems >>> confusing to me. >> >> Or a shorter name. > > Well, with "using std::move" it's a bit shorter (just "move ($n)"), > but still too much clutter for my taste.
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 * & ~ + -.
