Easy HashCode and Equals override

[eklam]

Proposition

An easy way to implement default HashCode and Equals method, similar to that implemented by anonymous types

Situation

If the HashCode and Equals are already implemented by the language in some situation, why I should reimplement it?
I got myself, doing this more than one time:

    public class SomeThing
    {
        public decimal Tax { get; set; }
        public decimal Comission { get; set; }

        // Etc...

        public override int GetHashCode()
        {
            return new
            {
                Tax,
                Comission,
            }.GetHashCode();
        }

        public override bool Equals(object obj)
        {
            var other = obj as SomeThing;

            if (other == null)
                return false;

            return new { Tax, Comission }.Equals(new { other.Tax, other.Comission });
        }
    }

Why not something like this:

    [DefaultHashCode]
    [DefaultEquals]
    public class SomeThing
    {
        public decimal Tax { get; set; }
        public decimal Comission { get; set; }

        // Etc...
    }

Or maybe:

    public class SomeThing
    {
        public decimal Tax { get; set; }
        public decimal Comission { get; set; }

        // Etc...

        public override object GetStrucuralProperties()
        {
            return new { Tax, Comission };
        }
    }

[nosami]

I would expect that allocating new objects to generate a hashcode would be terribly inefficient.

[eklam]

@nosami, just compiler job, could be done using macros before compilation. Also the [Attribute] suggestion doesn't generate new objects.

[Richiban]

While I love the suggestion and would have said "yes, one thousand times yes" a little while ago I think this may be redundant if C# gets record types. One of the features of records is that they have structural equality by default, which is what you're suggesting here.

However, this might still be useful, especially if records types don't make it into the language for whatever reason.

[eklam]

I also like the idea for record types, kind of the scala "case class", but I think the way I proposed feels more the C# way. Also a feel that adding a record type is just what a struct should be, adding class, structs and record type seems too much for beginners.

[Richiban]

I'm not sure case classes are analogous to record types; they're more the equivalent of discriminated unions, if you're familiar with F#.

A C# record type of your example would (under current suggested syntax) look like this:

public class SomeThing(decimal tax: Tax, decimal comission: Comission);

You get structural equality (along with hashcodes), immutability and ToString for free.

[gafter]

We prefer to avoid giving language semantics to attributes.

The proposed C# records are exact analogs to Scala's case classes, and would appear to address the underlying use cases.

[kodfodrasz]

As record classes are always upcoming, just like fusion reactors and flying cars, while the Java ecosystem has these for a decade at last I must to ask, why is this not reopened?

Pic related: developer waiting for record types:

[CyrusNajmabadi]

@kodfodrasz

why is this not reopened?

It appears as if there's very little interest. So, more important things are being appropriately prioritized.

[kodfodrasz]

It appears as if there's very little interest. So, more important things are being appropriately prioritized.

I wonder what are those more important things. The interest was suppressed with the promise of records being the solution (which they are not) and are already upcoming really soon™.

Records have still not arrived. We will have async ToString, async throws and async new sooner than getting rid of unmaintainable editor generated Equals and GetHashcode, which is a necessarry boilerplate if one wishes to use Sets or Dictionaries with a custom type, and 99% of the time the compiler generated solutions would be appropriate, and their update after extending with methods would not be forgotten. Also code would stay more readable. It would also lower maintenance costs for lot of legacy code, but who cares? Nobody is interested.

In the meantime just use valuetuples with named members...

I believe these cases better show the importance of the community feedback than the nice diagrams posted yearly by MS folks.

[CyrusNajmabadi]

I wonder what are those more important things.

The current set of 8.0 features for example :)

I believe these cases better show the importance of the community feedback

There has been minimal community feedback that this is an issue that warrants a lot of attention from MS. This issue alone only has a 10 posts from a handful of people.

[kodfodrasz]

The current set of 8.0 features for example :)

Those are nice features indeed.

Now what stops us from reopening this issue, to let the community provide feedback, now, when we can see that the promise of records solving this use case (which is not completely true anyway) has been a false excuse to close the issue, as a total of 5 language versions were released since the closure of the ticket, none addressing this point.

The lack of interest and discussion is not a valid excuse, as many are intimidated by seeing the issue as closed, and may think that the discussion is over, so they won't express their interest as it were still open. I truly hope it is not.