Discussion: New ability to describe what makes a class distinct

[ericwood8]

Discussion: New ability to describe what makes a class distinct

Purpose: So one can get rid of "Equality Comparers" and other Equals boilerplate for the majority of classes.

Core Benefits;

1. Ability to define WHAT you want compared when you want equality without custom implementation.
2. When a new field or existing field changes that matters in comparison, you just add it to the list of properties in the distinct list.
3. Makes it easier to find duplicates
4. Less code
5. Easier to create and maintain equality of instantiated class objects, but still being flexible enough that you don't need it to still do it the old way

Why?: "Equality Comparers" and HashCodes are: 1) Boring, 2) error prone, 3) not DRY, 4) wastes development time, 5) you should write a test for the equality comparers if you are doing TDD. 6) Brittle - If I add a new column or change existing distinct columns, I have to change both the Equality Comparer and HashCode, The only real code of significance is what columns are we want to be distinct.

New Keyword in Context of the Class: DISTINCT (its usage shown below)

Class Example:

internal class AnchorCellConfig
   distinct ( SetName, WorksheetName, CellShortName, CellText ) // ***** <= NEW *****
{
   public string SetName { get; set; }
   public string WorksheetName { get; set; }
   public string CellShortName { get; set; }
   public string CellText { get; set; }
   public int ExpectedRow { get; set; }
   public int ExpectedCol { get; set; }
}

In the example given:
ExpectedRow and ExpectedCol do not matter comparing the equality of these objects, but the others do. Example given is from real world. We have app that reads from a YAML configuration that users could change. We read the YAML into an class. We wanted to prevent duplicate rows because users could have entered a row twice. So wanted to be able to determine row distinctness so we don't want duplicates.

New Compiler Restrictions:
1) The compiler should error if the properties in the Distinct are not properties in that class. So in the example "SetName" and all the others must be a property on the AnchorCellConfig class.
2) The compiler should error if object has another EqualityComparer on it.

New Compiler Actions:
It could construct a EqualityComparer for you behind the scenes. This is now the new default EqualityComparer of the object.

Existing C# language impacts:

1. Linq's Distinct() should use this, no longer needing an EqualityComparer
2. Equals() comparisons should use this

Equality boilerplate no longer needed:
NOTE - This is the shortest version of an EqualityComparer I can think of:

internal class AnchorCellConfigComparer : IEqualityComparer
{
   public bool Equals(AnchorCellConfig x, AnchorCellConfig y)
   {
      if (ReferenceEquals(x, y)) // Do compared objects reference the same data?
      {
         return true;
      }
      else if (x is null || y is null) // Is either compared object null?
      {
         return false;
      }
      return x.SetName.Equals(y.SetName) &&
                x.WorksheetName.Equals(y.WorksheetName) &&
                x.CellShortName.Equals(y.CellShortName) &&
                x.CellText.Equals(y.CellText);
   }

   public int GetHashCode(AnchorCellConfig acc) => acc.SetName.GetHashCode() ^ acc.WorksheetName.GetHashCode() ^ acc.CellShortName.GetHashCode() ^ acc.CellText.GetHashCode();
}

Clarification: The DISTINCT keyword and line are not required. This does not remove old EqualityComparers and Hashcodes from existing objects. Nor does it prevent using EqualityComparers and Hashcodes for specialized comparisons.

[DavidArno]

Above cartoon is from the excellent xkcd webcomic

OK, maybe I'm being unkind with the above, but there's a lot of truth in it. The point is, history has repeated shown us that the one effect you will not achieve with this is to "get rid of "Equality Comparers" and other Equals boilerplate", for many people will stick with old ways of doing things. So this will just become yet another way of doing equality that one must learn.

Plus I don't really see what this proposal offers that records don't offer with even less boilerplate. But maybe I missed something?

[HaloFour]

Sounds like a good use case for a source generator.

[ericwood8]

In defense of what I am proposing: I hate having to write a bunch of Equality Comparers and HashCodes. Boring, error prone, not DRY, wastes development time, you should write a test for the equality comparers if you are doing TDD, etc. If I add a new column or change existing distinct columns, I have to change both the Equality Comparer and HashCode, The only real code of significance is what columns are we want to be distinct.

As for source generator suggestion, why do that? You as the developer would have to tell VS what are the distinct columns anyway and then with the longer generated code - why would you want more code to maintain?

@DavidArno, As for the "for many people will stick with old ways of doing things" attitude, why even read and comment and accept any new features?

[alrz]

Equality Comparers and HashCode

records can generate Equals and GetHashCode for you but for anything outside the default logic you should provide your own impl, obviously.

[333fred]

As for source generator suggestion, why do that? You as the developer would have to tell VS what are the distinct columns anyway and then with the longer generated code - why would you want more code to maintain?

Well, equality has a lot of variations and flavors. For example, there are 6 different ways to compare strings built into the framework. You could have a collection that you might want to compare by sequence equality, or by reference equality. A language feature maybe could encompass all of these, but there are an infinite number of ways that a user could conceivably want to customize equality, so we explicitly do not want to have these points in the language itself. As to separately maintained code: I don't see why it would have to be separately maintained? There's no reason that a source generator couldn't generate the distinct columns for whatever other thing you need them for, or generate equality based on what you specify for other distinct columns you have.

[HaloFour]

As for source generator suggestion, why do that?

Because a source generator can apply any kinds of policies. It starts with a subset of the fields, then it explodes into how each and any of those fields are compared to each other. There are too many individual opinions to apply here, which is why it doesn't belong within the language.

The language design group has already considered this problem during the design of records, as it was quickly requested to have a way to customize the equality of those types in different ways. The team decided that the appropriate escape hatch was to let the developer provide their own Equals/GetHashCode implementations, which is entirely open-ended. Source generators would fit in perfectly as they can then provide those implementations and let the developer pick and choose policy based on the ecosystem of generators and the configuration via attributes that they can support.

[ericwood8]

@alz, my proposal dealt nothing with "records" (which don't exist in C# but are suppose to eventually: https://devblogs.microsoft.com/dotnet/welcome-to-c-9-0/ ).

@333fred, I had not considered different types of equality. But nothing in the proposal says the "Distinct" line is required to create a class. I was not proposing removing the old code. So if you had a specialty equality, you would just use the older way of EqualityComparer and HashCodes.

[alrz]

which don't exist in C# but are suppose to eventually

Yeah it is available in preview and you can give it a try today. (oh I have a bias towards solving problems with existing features)