Is Int32.ToString() culture-specific?

Solution 1:

The Operating System allows to change the negative sign for numbers.

Control panel -> 
   Language and regional settings -> 
         Additional settings -> 
             Negative sign

So, current culture could have overridden the negative sign. In this case you need to respect the regional settings, this is the reason of the warning. You can also change the negative sign programatically:

    CultureInfo culture = Thread.CurrentThread.CurrentCulture;
    // Make a writable clone
    culture = (CultureInfo) culture.Clone();
    culture.NumberFormat.NegativeSign = "!";

Solution 2:

As tested on a random sample of ints, all 352 cultures installed with Windows (CultureTypes.InstalledWin32Cultures) give identical results.

Daniel is right to note a custom culture could use a different prefix for negative numbers, but I doubt anyone has ever used this feature save by accident.

I guess the .NET devs did it to be consistent with float and other types. What else were they expecting?

> int.MaxValue.ToString(CultureInfo.AncientRome)
MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM....

Solution 3:

It's weird; I would have expected 50.ToString(CultureInfo.CreateSpecificCulture("ar-AE")) to return "٥٠", but it doesn't.

I've just looked this up, and the problem seems to be that NumberFormatInfo.DigitSubstitution isn't actually implemented

The DigitSubstitution property is reserved for future use. Currently, it is not used in either parsing or formatting operations for the current NumberFormatInfo object.

So, although there is an enumeration System.Globalization.DigitShapes, it's not actually implemented in the NumberFormatInfo bit of IFormatProvider.

Solution 4:

Yes. It depends on the current culture. From the MSDN docs:

The return value is formatted with the general numeric format specifier ("G") and the NumberFormatInfo object for the current culture.

emphasis mine

Resharper just most likely wants you to be explicit about what culture you are intending to use. Since omitting it relies on behavior that may change when executed on different machines.

Solution 5:

The compiler is (unnecessarily) warning us about it COULD be casted to string somehow not as we expected it to be. For example:

int i = 1;
Console.WriteLine("i.ToString='{0}'", i.ToString());

We all expect it to return as '1' but it is not 100% guaranteed because .ToString() method gets affected by the current thread culture. It CLAIMS that it could return as '1.00' or something like that but I tested it with a really small code:

foreach(CultureInfo ci In System.Globalization.CultureInfo.GetCultures(CultureTypes.AllCultures) {
        Console.WriteLine("RESULT='{0}' CultureCode: {1} EnglishName:{2}", i.ToString(ci), ci.Name, ci.EnglishName);
        if (!i.ToString(ci).Equals("1"))
            throw new FormatException()
}

The code never returned any error. So, it actually never returns anything other than "1".

As far as there will be a new country with a brand new native super-weirdo language in this world that actually spells "1.00" for an integer, we can keep using just .ToString() without any doubt.

Cheers!

Output was: