fix: strictly check operator overload ambiguity

[HerrCai0907]

operator overloads are merely an internal mechanism, primarily for string implementation, operator overload can support to compare user-defined class, but it need to be limited.
a == b and b == a should run the same function and get the same result in semantic level. Allowing ambiguity is bug prone.
fixes: #2761

[dcodeIO]

Perhaps AS240: Operator '==' overload ambiguity (choosing 'A#__eq' over 'B#__eq').?

[HerrCai0907]

Perhaps AS240: Operator '==' overload ambiguity (choosing 'A#__eq' over 'B#__eq').?

Maybe
AS240: Operator '==' overloading ambiguity (candidate overloads 'operator-overload-ambiguity/A#__eq' and 'operator-overload-ambiguity/B#__eq').

[CountBleck]

AS240: Ambiguous operator overload == (conflicting overloads 'operator-overload-ambiguity/A#__eq' and 'operator-overload-ambiguity/B#__eq') possibly.

[HerrCai0907]

ping @dcodeIO@CountBleck

[HerrCai0907]

@CountBleck@dcodeIO Could I land it now?
Since it introduces a break change, how can I upgrade minor version for AS? I remember daily publishing action will upgrade patch version.

[CountBleck]

I can't say all that much about the contents of the PR. @dcodeIO knows what's best.

To upgrade the minor version, you need the BREAKING CHANGE: or major: prefix, so merging the PR as-is should work.

[HerrCai0907]

friendly ping @dcodeIO

[dcodeIO]

Could this become a warning that mentions which overload has been picked by the compiler? Similar to my prior comment:

AS240: Operator '==' overload ambiguity (choosing 'A#__eq' over 'B#__eq'). 

Or do you think that there are good reasons to make it an error and hence a breaking change?

[HerrCai0907]

I think we should forbidden this behavior because:

1. a == b and b == a should be the same thing. It is so crazy if someone gets true from the first expr and gets false from the second.
2. Since this is an extended grammar, we don't have references from TS. The language which supports operator overloading (I only know cpp) also have similar behavior.

[dcodeIO]

Given that operator overloads are merely an internal mechanism, primarily for string implementation, and not recommended to be used for anything custom anyway as these won't typecheck, I guess it's fine to check these strictly and error otherwise. More generally, I'd probably even prefer that we limit their use, and encouraged the use of .equals methods or similar in own code, and with it eliminate the ambiguity this PR resolves.

[HerrCai0907]

I'd probably even prefer that we limit their use, and encouraged the use of .equals methods or similar in own code

Agree.
And I guess it will not break any actual code because nobody will consciously write two different comparison function.

[HerrCai0907]

I treat it as a fix instead of a break change since it should not break any user code. @dcodeIO WDYT?