[API Proposal]: String.EqualsIgnoreCase()

[terrajobst]

Background and motivation

As stated in #14065 invoking string.Equals with the comparison overload feels unintuitive. I believe this comes from two reasons:

1. Ordinal isn't something people think of when comparing strings. It feels like low-level lingo.
2. Operands are often compound expressions, which either forces me to assign them to a temporary or live with the fact the operation (Equals) and the way it's being conducted (Ordinal, OrdinalIgnoreCase) is split far part. One place where using a temporary is often not desirable is in lambda expressions where doing so requires converting the expression into a statement block. In case of LinQ this can start to feel really bulky. I have often resorted to extracting helper functions that just do the comparison, but that feels heavy handed too.

Since String.Equals is doing an ordinal comparison anyway, it seems we could address some this by just introducing EqualsIgnoreCase.

API Proposal

namespace System;

public partial class String
{
    public static bool EqualsIgnoreCase(string? a, string? b)
    {
        return Equals(a, b, StringComparison.OrdinalIgnoreCase);
    }
}

API Usage

Before:

var result = docs.Where(d => string.Equals(d.DocumentInfo?.DocumentType, "BusinessReport", StringComparison.OrdinalIgnoreCase);

After:

var result = docs.Where(d => string.EqualsIgnoreCase(d.DocumentInfo?.DocumentType, "BusinessReport");

Alternative Designs

• String.Equals() already is doing an Ordinal comparison. So just naming it EqualsIgnoreCase rather than EqualsOrdinalIgnoreCase makes more sense.
• We could decide to include the other enum members of StringComparison as well, but I don't think they are used enough to warrant this, but they could of course be added later.
• String.Equals isn't intuitive and forces us to do the OrdinalIgnoreCase thing #14065 points out that Ordinal and OrdinalIgnoreCase aren't intuitive terms, which this proposal partially addresses by removing Ordinal.

Risks

None that I can think of.

[terrajobst]

(Realized after submitting that String.Equals() is already doing ordinal. I've simplified the proposal to reflect this)

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-runtime
See info in area-owners.md if you want to be subscribed.

[DHowett]

My couple cents: I think introducing a convenience API with a name that omits "Ordinal" is loading and aiming a footgun. If it does not do a locale-sensitive case comparison, it should not be named in a way that will trick generations of future developers into thinking it does.

[clemensv]

.NET makes developers aware of case folding not being straightforward by having these options on the comparison overloads. This new function is moving this out of (Intellisense-) view.

There are two competing scenarios for comparing strings:

a) comparing identifiers and similar "technical" user cases
b) comparing other text content

Ordinal is good for a). You will want culture-aware comparisons for b)

[ladeak]

There is already a good way doing this, saving the extra StringComparison param does not seem a significant win for me.
I think this is a convenience API that you can easily add as a static method on string with C# 14's extensions feature.