Add support to configure culture/casing of string properties on record types

[CarlosHAraujo]

I ran into the common surprise with records: the compiler-generated equality for record members uses the default equality for each member type, so string members are compared case‑sensitively. That’s the right default in many cases, but it’s awkward when your domain expects case-insensitive string equality (e.g. identifiers, file extensions, user names, tags, etc.).

public record Person(string Name);
Assert.Equals(new Person("John"), new Person("john")); // assert fails

There’s already a clear report/discussion on csharplang about this: dotnet/csharplang#6994 —
In that thread, OP suggests that a StringComparisonAttribute could be helpfull to control how the properties should be compared, but CyrusNajmabadi pointed out this is something that should be filed against Roslyn (the language choice to leave it out was intentional).

Seems like the OP never took the time to move the discussion here, so I'm doing it.
I'd like to propose:

• Provide an opt‑in attribute that the compiler recognizes when synthesizing record equality/hashing:
  • Example: [StringComparison(StringComparison.OrdinalIgnoreCase)] on a property or on a primary‑constructor parameter.
  • Compiler then emits string.Equals(a, b, StringComparison.X) for equality and uses a matching hash code.
• Keep defaults unchanged (unless attribute present).
• The attribute is precise and scoped: per‑member, so records can mix case‑sensitive and case‑insensitive string fields.

So, one could do this:

[StringComparison(StringComparison.InvariantCultureIgnoreCase)]
public record Person(string Name);
Assert.Equals(new Person("John"), new Person("john")); // assert pass

Would love to hear whether the Roslyn maintainers are open to this approach (or whether there’s another low-friction path you’d prefer).

[CyrusNajmabadi]

You can already accomplish this today. Just write a source generator that spits out an appropriate .Equals and GetHashCode based on whatever attributes you care about. The language or Roslyn doesn't need to do anything here as the extensibility point is already available.

[333fred]

Very related to dotnet/csharplang#5767, dotnet/csharplang#4257, and dotnet/csharplang#8245 as well.

[RikkiGibson]

What I am seeing folks sometimes do in practice is to define a wrapper type, which performs the comparison on the underlying type in the desired way, and use that as the member type in the record instead. For example EquatableArray from @Sergio0694 (Sergio, I can't find the link to it, do you have that handy?). So, for example, perhaps the string Name could instead be an EquatableString that you define, which has Equals and GetHashCode on it which behave in the way you want, and allows access to the underlying string.

[Sergio0694]

Sure! Here's one 🙂

Also my 2 cents: I'd love to just be able to slap an attribute on the record property to inject a custom IEqualityComparer<T>.

[333fred]

It has always been our position that a source generator is the appropriate knob for that, and it continues to be our position that this is true.