String.Equals isn't intuitive and forces us to do the OrdinalIgnoreCase thing

[shanselman]

We're doing a sample and we are FOREVER doing this

if (sort.Equals("Title", StringComparison.OrdinalIgnoreCase))

I think it's time for an overload or an extension that "does the right thing." This is a 10 year old pattern and if the default is wrong (as we tell people to do this) then let's make a better method. Everyone has a version and extension that does this.

[jongalloway]

I agree +10e8

[madskristensen]

+1

This drives me nuts and forces me to do multi-line if statements due to very long lines this produces. I hate that. A better and much shorter syntax would be super awesome!

[rustd]

the default should really be changed as most apps have to have this check

[Bhaal22]

+1
Makes me crazy.

[csharpfritz]

Agreed - lets help our community by making the framework use the correct pattern by default

[joshfree]

var oic = StringComparer.OrdinalIgnoreCase;

if (oic.Equals(sort,"Title"))

[ellismg]

I'm not pushing back against this request, but does someone have a strawman to kick off the design? The best thing I can think of is: EqualsOrdinalIgnoreCase as a method on String. Is this still too long?

[shanselman]

Why not EqualsIgnoreCase. Is Ordinal that obvious, or needed? (although semantically it would be implied.)

[ellismg]

@shanselman I guess that's reasonable. Personally I dislike how some operations on the string class do linguistic comparisons where as others do ordinal and it's not clear from the method name what's going on. This proposal would be making the problem worse, but perhaps we should optimize for folks that have already learned for each method if it's doing ordinal or linguistic conversions.

[shanselman]

@ellismg I hear you. I'm trying to optimize for the 80% or even the 90% case. What is the "pit of success" option? What's the one that if folks who don't know the difference pick is more likely to be correct?

[plemanach]

+1 EqualsIgnoreCase

[davkean]

@rustd Are you suggesting that ignore case should be the default? Changing defaults around this is pretty much a non-starter. We've tried similar things in the past (such as switching all operations to ordinal and invariant by default in Silverlight) but ended up backing it out for a variety of reasons. There's just too much legacy code being copied and pasted around.

I like static bool EqualsIgnoreCase(string, string) and bool EqualsIgnoreCase(string), it fits in with existing overloads static bool Equals(string, string) and bool Equals(string) which already do a ordinal comparison.

[ebickle]

@davkean @shanselman Agree on EqualsIgnoreCase.

I did a quick scan through the String class, other methods that take a StringComparison overload include Compare, CompareOrdinal, CompareTo, StartsWith, EndsWith, IndexOf, LastIndexOf, Replace. None of them seem like a high priority for an IgnoreCase overload.

What's painfully missing is a Contains overload that accepts a comparison type. It's a bigger functionality gap than EqualsIngoreCase.

public bool EqualsIgnoreCase(string value);
public static bool EqualsIgnoreCase(string a, string b);
public bool Contains(string value, StringComparison comparisonType);

This may be a bit more of a stretch, a new IStringEquatable interface could be introduced that inherits from IEquatable. IStringEquatable would add the necessary overloads for the comparison type.

public IStringEquatable<T> : IEquatable<T>
{
    bool Equals(T other, StringComparison comparisonType);
}

The C# team is currently looking at potentially implementing pattern matching and improvements to the switch statement for C# 7.0. One source of pain has been the inability to do case insensitive comparisons in a switch statement - introducing the interface would provide a hook for case insensitive comparisons as 'syntactic sugar'. The interface could be added to the other string-like types, such as HtmlString.

I never quite understood why languages don't introduce a case-insensitive string comparison operator. It's likely that because it only applies to a string, it doesn't meet the bar required for a broadly used language feature. That said, the same was once true for String types themselves (just use an array!). Case-insensitive string comparisons are a very bread & butter development operation, and as noted above can apply to types other than System.String.

Imagine the theoretical ==~ and !=~ operators (the tilde being the approximation symbol, not bitwise complement):

public static String overload ==~(String a, String b)
public static String overload !=~(String a, String b)

if ("CoreFx" ==~ "corefx") // true

Even aside from theoretical language changes (very unlikely), the interface would allow libraries such as LINQ to leverage case-insensitive string equality natively without resorting to reflection. The same holds true for String.Compare, which strangely is missing a non-static String.Compare(string, StringComparison) overload.

[shanselman]

I love the possible case-insensitive string operators. Until then, let's do
EqualsIgnoreCase.

On Fri, Feb 6, 2015 at 10:06 AM, Eric Bickle notifications@github.com
wrote:

@davkean https://github.com/davkean @shanselman
https://github.com/shanselman Agree on EqualsIgnoreCase.

public bool EqualsIgnoreCase(string value);
public static bool EqualsIgnoreCase(string a, string b);

I did a quick scan through the String class, other methods that take a
StringComparison overload include Compare, CompareOrdinal, CompareTo,
StartsWith, EndsWith, IndexOf, LastIndexOf, Replace. None of them seem
like a high priority for an IgnoreCase overload.

This may be a bit more of a stretch, a new IStringEquatable interface
could be introduced that inherits from IEquatable. IStringEquatable would
add the necessary overloads for the comparison type.

public IStringEquatable : IEquatable
{
bool Equals(T other, StringComparison comparisonType);
}

The C# team is currently looking at potentially implementing pattern
matching and improvements to the switch statement for C# 7.0. One source of
pain has been the inability to do case insensitive comparisons in a switch
statement - introducing the interface would provide a hook for case
insensitive comparisons as 'syntactic sugar'. The interface could be added
to the other string-like types, such as Char, StringBuilder, and HtmlString.

I never quite understood why languages don't introduce a case-insensitive
string comparison operator. It's likely that because it only applies to a
string the logic is that it doesn't meet the broad use needed for a general
language feature. That said, the same was once true for String types
themselves (just use an array!). Case-insensitive string comparisons are a
very bread & butter development operation, and as noted above can apply to
types other than System.String.

Imagine the theoretical ==~ and !=~ operators:

public static String overload ==(String a, String b)
public static String overload !=(String a, String b)

if ("CoreFx" ==~ "corefx") // true

Even aside from theoretical language changes (very unlikely), the
interface would allow libraries such as LINQ to leverage case-insensitive
string equality natively without resorting to reflection. The same holds
true for String.Compare, which strangely is missing a non-static String.Compare(string,
StringComparison) overload.

—
Reply to this email directly or view it on GitHub
https://github.com/dotnet/corefx/issues/649#issuecomment-73284160.

Scott Hanselman
Donate to fight diabetes: http://hnsl.mn/fightdiabetes