3 ms·

The default comparison should be a culture neutral comparison. Just like the default number formatting unless specified should default to "NumberFormatInfo.Inva

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).

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).