Why can = operator not be overloaded with member function?

Hello,
i want to know the reason as to why can't the = operator be overloaded with friend function of the class?why do we only have to use the member function??

this is the code :-

Code:

#include <iostream.h>
class set
{
   int data;
   public:
	   void getdata(int);
	   void putdata();
	   void operator=(set);
};
void set::getdata(int a)
{
	data=a;
}
void set::putdata()
{
	cout<<data;
}
void set::operator=(set b)
{
	data=b.data;
}

int main(void)
{
 set a,b;
 a.getdata(5);
 a.putdata();
 b=a;
 cin.ignore();
 cin.get();
return 0;
}

Please use friend function instead of this and tell me whether it can be overloaded or not?and if not then why?

Simply put, because the standard says so. I don't know the actual reason, and Design and Evolution doesn't elaborate.

Could this have anything to do with the fact that the compiler would generate assignment operator automatically unless you define it yourself as a class method?

It's as good a guess as any. Makes sense.

A further suggestion to you:
Use appropriate variable names (this may just be an example so I don't know if you do it in real code) and also use appropriate variable names in prototypes and class definitions.

It could be an oversight. See Non-member overloaded copy assignment operator.

It was no oversight. The actual reason for the constraint is encapsulation.

operator=() acts on it's left hand operand (i.e. "a = b" changes a directly; it does not create any temporaries, new objects, etc). operator=() is therefore part of the interface of the class. Allowing it to be a non-member function would allow other, unrelated, code to arbitrarily change how assignment works for the class. i.e. it would allow other code to directly change the class interface, and potentially introduce new behaviour that breaks the class, without knowledge of the class designer.

constructors and destructors are required to be member functions for the same reason.

It prevents things like this;

Code:

class BigInteger
{
     // all sorts of things to make class work
};

// some evil code

//  create an assignment operator with the body that effectively does this regardless of RHS

BigInteger operator=(BigInteger &lhs, const BigInteger &rhs)
{
    lhs.SetContents(42);   // set *this to be value of 42 regardless of value of rhs, and without knowledge of original class designer
}

Allowing it to be a non-member function would allow other, unrelated, code to arbitrarily change how assignment works for the class. i.e. it would allow other code to directly change the class interface, and potentially introduce new behaviour that breaks the class, without knowledge of the class designer.

Section 3 of the proposal I linked to outlines possible solutions to this problem.

I was not arguing there are no alternatives. I was explaining the reasoning behind it being as it currently is.

The proposal you linked to would actually allow the sorts of problems I described in certain circumstances, not prevent them.

There are always debates between people who want features for convenience and those who want to disallow such features because those features can be misapplied. This is one of those cases. Personally, I consider the proposal you linked to will introduce more problems than it solves.