4 ms·

Such a Anglo centrist view. Rest of the world be damned? Luckily a not all the .Net creators were English speakers.

• ygra 5y ago
  It's probably an unfortunate decision either way: For interacting with things the user types the ordinal approach is wrong, but for low-level handling of text the ordinal approach is faster. In both cases you basically have to know your exact needs and choose the correct variant. You could have the parameter not being optional and thus force every user of that API to make that decision, but that is probably fairly quickly perceived as annoying.
  • AtNightWeCode 5y ago
    Ordinal is the default comparison for most .NET string methods. Most linters will force you to make an active choice. And it is not only a performance thing since you open up for all these Unicode attacks.
• torginus 5y ago
  Not an Anglo. Still think it's dumb. Most of the strings I manipulate are either english, or not even natural languages. Having to write Ordinal for Regex and string comparisons everywhere sucks. Especially considering that if you don't, it will depend on the current thread's Culture setting, which can lead to odd bugs when you call code from different contexts.
• alkonaut 5y ago
  The default comparison should be a culture neutral comparison. Just like the default number formatting unless specified should default to "NumberFormatInfo.InvariantInfo" rather than "Thread.CurrentThread.CurrentCulture". If I want to compare or print in my own language or the system language (I very rarely do) then I'm happy to specify that in code. And I wish the API forced me to, because I some times forget and I make code that breaks when it's run on a different machine. Which is almost never what I want.
  • int_19h 5y ago
    If there's only a single string type, there should be no default comparison at all. There are many cases where ordinal or culture-invariant comparison is wrong (almost any string that can be potentially displayed in UI). There are also many cases where ordinal is the only thing that is correct. The only way to prevent sneaky bugs is to force the dev to think it through every time they have to compare strings. (It should also be easy to compare strings in different ways. StringComparison.Ordinal is an overly long incantation for the frequency with which it's needed.) Alternatively, we need two distinct string types - one for "displayed text", and one for internal stuff like an HTTP header - with no implicit conversions between the two, and with comparisons defined differently for either.
    • alkonaut 5y ago
      For comparison I’d be happy to force a comparer and never assume anything. But the problem can also be flipped around and generalized to include formatting. To seem well designed I think it should be symmetric in formatting/parsing wrt what must be provided. In formatting it’s more clear that the system must assume assume format, or some operations become unergonomic (once one wants to be sloppy and allow concatenation of string and int for example). But perhaps one could compromise and just allow ints (assume invariant) but not floats (require formatter).
• Denvercoder9 5y ago
  How is defaulting to byte-comparing strings Anglocentrist?
  • viraptor 5y ago
    The idea that you can byte-compare strings is ascii-centrist. Others will ask "are they even using the same encoding", "are they normalised the same way" first.
    • Denvercoder9 5y ago
      Those things only matter when your strings contain human-oriented text, but that's not the only (and dare I say not even most common) usage of strings. Obviously it's best to be explicit about how you want the contents of your strings to be treated, but absent that, I don't see how defaulting to ordinal string comparison is Anglo-centric. The English culture doesn't use ordinal comparison. Defaulting to ordinal comparison can actually _prevent_ breakage for people using non-English cultures, because strings suddenly behave differently in ways the developer didn't anticipate or test. (Also, I should've said codeunit-compare instead of byte-compare, since C# strings are always UTF-16 encoded).
    • jameshart 5y ago
      .NET strings are backed by two-byte UTF-16 codepoints, not bytes in an unknown encoding. But ordinal comparison means ignoring equivalence classes, like U+006E (n) + U+0303 (combining tilde) being considered the same as U+00F1 (ñ). But - perhaps more surprisingly - .net's non-ordinal match also matches things like "ß" and "ss". That leads to some weird things like even if two strings compare as equal in the invariant culture, if you uppercase them in the invariant culture they may no longer be considered equal. And that's all before you start looking at culture-variant behaviors like different cultures having different casing rules (see Turkish dotless i) or approaches to diacritic equivalence for sorting.
• AtNightWeCode 5y ago
  The default and recommended way of comparing strings in .NET is with ordinal comparison. It is just some functions that use CurrentCulture instead for some reason. We are also talking about Unicode strings here so you can compare strings in any language.