4 ms·
Even though it makes sense with regard to the way operators work currently (they can be defined as members, or as free functions), it looks like a breaking chan
by nly 12y ago
Even though it makes sense with regard to the way operators work currently (they can be defined as members, or as free functions), it looks like a breaking change to me
struct A {
double magic(int);
};
string magic(A&, int);
is currently legal code. Under this proposal they'd effectively be overloads with different return types, which is is a compile-time error, unless I'm missing something.
- adrusi 12y agoIn order to maintain compatability, magic(a,b) would have to call the nonmember function and a.magic(b) would call the member function. Ideally, if you were using this feature, you would enable a warning that tells you if there's a collision like this in any scope. Otherwise, your code would continue to work just as it already does. Unless I'm missing something, I don't think this proposal would break anything, and while the edge behavior for collisions is awkward and unfortunate, at least its easy to identify and avoid