Generate a default '==' for struct types that haven't explicitly defined it

[YT-GameMaker]

I believe that the current method of equality comparison is outdated and should be replaced with == instead of Equals. For those structs that do not have a explicitly defined ==, default == should be generated for them, and it would recursively call == for each field, this allows any custom == defined within subfields to be correctly invoked.

Object implements == by comparing whether two references are equal. References of all types are considered the same thing, and == between any two references defaults to the == of Object, unless their class have explicitly defined ==.

This way, you can confidently compare any two objects of the same type, and in most cases, the default implementation should meet the requirements and offer good performance.

struct Data : IEqualityOperators<Data, Data, bool> // always implement this interface
{
    float a;
    object b;
    InlineArray<int, 8> c;
    
    // Generated
    public static bool operator ==(Data x, Data y)
        => x.a == y.a && x.b == y.b && x.c == y.c;
}

In this example, a is a primitive type, and its == has been explicitly defined. b is a reference type, and its == compares references themselves rather than the objects they reference. c is a nested struct, and its == depends on its internal implementation.

[CyrusNajmabadi]

.Equals is literally the way to do equality for .net and has been for literally 25 years. It works well, as designed, and is not something we have any desire to change. If it ain't broke, don't fix it.

[YT-GameMaker]

By default, it's not possible to use the == operator on generic types, which can be one of the most frustrating limitations. While there are workarounds, the true essence of improving the language lies in providing better solutions.

[tannergooding]

It has been explained multiple times on multiple related issues, all asking for essentially the same thing here, that == and Equals are not equivalent. It is not and never will be valid to universally replace one with the other. It is not bettering the ecosystem to start requiring or pushing users to make == available.

Likewise, == does not always exist, while Equals does, and there is 15+ years of existing code that cannot use == due to it requiring binary breaking changes. You will have to get used to that.

---

The number of issues you've opened on this topic is likewise starting to border on the realm of spam. Please keep discussions to the existing relevant issues rather than opening new ones. So far, you have opened:

• Replace IEqualityComparer with "==" interface #7641
• It's time to use "==" to check if objects are equal runtime#94269
• Make '==' have a default behavior similar to IEqualityComparer<T>.Default ? #7645

You also opened #7646, which was touching on the same general topic.

Beyond that you also opened #7648, where you admitted to not reading the existing proposal. Which means you did not first attempt to see if the issue covered your idea, what pros/cons were called out, what kind of limitations the existing type system may have that prevent such functionality, etc

[YT-GameMaker]

I didn't want to create a new discussion in the first place because I knew it would bring about disruptive changes. That's why I created a new discussion specifically to talk about all these disruptive changes. However, that discussion was closed because you don't allow comprehensive discussions. Furthermore, he said that the discussion language is pure and doesn't consider engineering issues. So I created a new discussion, but now I find that all of my discussions have been closed, including one about const generics that is different from others' ideas... Maybe you can consider providing a place specifically for discussing things that won't be implemented, or explicitly state that disruptive changes won't be considered.

[CyrusNajmabadi]

Maybe you can consider providing a place specifically for discussing things that won't be implemented,

Feel free to use your own blog for that sort of thing, or feel free to just discuss that stuff on any of our discord channels.

Those places are fine for these topics that are out of scope for these projects. If you do want to discuss this here, please listen to the moderation and abide by the rules here.

Thanks!

[tannergooding]

We notably also have comprehensive details on the general language design process and what is or is not expected in the repo readme: https://github.com/dotnet/csharplang

Discussions in general are fine, but taking breaking changes to the language or ecosystem requires significant justification and reasoning showing why it is better. It should not be able to be trivially shot down by explanations on why we have two related, but ultimately different, things (such as operator == vs Equals).

C#/.NET are over 20 years old. They have an existing ecosystem to support and they have a very high backwards compatibility bar as one of their most prominent features. As such, things that are basically personal syntactic preference would never fall into this category of acceptable change and discussions won't go anywhere (optional semicolons is another example of something requested that has been treated as "never").

[theunrepentantgeek]

For those structs that do not have a explicitly defined ==, default == should be generated for them, and it would recursively call == for each field, this allows any custom == defined within subfields to be correctly invoked.

This would be a significant breaking change. Existing code that depended on the current behaviour would now give different results.

Regardless of whether the change makes the code _more correct) or not (and that's a point that would be vehemently argued), the fact it would break existing code for nebulous benefit makes this a non-starter.