[Development] operators as members or not

[Mitch Curtis]

On 08/15/2013 09:40 AM, Olivier Goffart wrote:
> On Thursday 15 August 2013 03:11:20 Glen Mabey wrote:
>> Hello,
>>
>> I'm working on a couple of new classes and I wonder whether there is a
>> policy (written or otherwise) on whether operators should be members or
>> not.
>>
>> In particular, this question has come up in
>>    https://codereview.qt-project.org/#change,59605
>> and
>>    https://codereview.qt-project.org/#change,60792
>>
>> I am no C++ philosopher, but I understand that some authorities (like
>> stackoverflow) have their reasons for asserting that operators should not
>> be members -- they also cite some sources.
>> http://stackoverflow.com/questions/4421706/operator-overloading/4421729#442
>> 1729
>>
>> Looks like Oliver Goffart did also weigh in on the issue, in 60792.
>>
>> Is it possible that the Coding Conventions could be amended to indicate
>> which way this issue should go, if only for new classes?
>
> The stack overflow answer says it well:
>
> Binary operator that treat both their member equaly should not be member.
> Because, in addition to the other reason mentioned in the stack overflow
> answer, the member are not equals when the operator is a member.
>
> Example with QLineF which unforortunatelly has its operator== as a member:
>
>   QLineF  lineF;  QLine lineN;
>
>   if (lineF == lineN) //Ok,  lineN is implicitly converted to QLineF
>   if (lineN == lineF) //Error: QLineF cannot be converted implicitly to QLine,
>                             // and the LHS is a member so no conversion applies
>
> If the operator== was outside of the class, conversion rules would applies
> equaly for both sides.
>
>
> Some Qt classes have their operator as a member, but it is a mistake that we
> cannot fix without breaking binary compatibility. But new operator should be
> outside of the class.
>
>

I've added this to the Qt Coding Conventions wiki: 
http://qt-project.org/wiki/Coding-Conventions#b3c5827f54218753bb2c3338236446c2