The operator+ implementation is essentially providing client code as efficient a recipe as possible for using operator+= automatically in addition expressions. I don’t really have any problems with slightly different signatures so long as they don’t introduce any semantic gotchas.

As for slicing, because operator+ creates a new object, it’s only really fully applicable to types with value semantics. For this reason I don’t really consider slicing a particular issue.

Consider the following.

class Derived : public Base { /* … */ }

Base operator+( const Base& l, const Base& r ) { /* … */ }

Whatever the details of the implementation, if there is no operator+ defined for Derived types, then the expression d1 + d2 will take two values of derived types and return a result whose complete type is just Base. Conceptually, the answer is sliced from what it could (should?) have been, even if neither parameter has been sliced in and of itself.

My preferred method of eliminating slicing concerns is to keep base classes abstract and to only implement free operator implementations for the most derived concrete classes.

I had this exact issue several months ago in some code I was refactoring. Some operator methods had ‘unusual’ pass by value parameters – it just looked (and smelled) wrong. It was only when I delved into the details I realised why this was happening: to save an explicit copy.

It stood out like a sore thumb in the header because “we never pass classes by value, right kids?”.

Is there not a concern for unintentional slicing here as well?