Is it expected behaviour of string.Format?

[Maximys]

Hello everybody. Today I found extremely strange behavior of string representation of decimal struct. But first let's look at the following code:

decimal value1, value2;
bool isValue1EqualsToValue2, isStringRepresentationOfValue1EqualsToValue2;

value1 = 10.0M;
value2 = 10M;

isValue1EqualsToValue2 = value1 == value2;
isStringRepresentationOfValue1EqualsToValue2 = string.Format(CultureInfo.InvariantCulture, "{0}", value1) == string.Format(CultureInfo.InvariantCulture, "{0}", value2);

Console.WriteLine($"\"{nameof(isValue1EqualsToValue2)}\"={{0}};\n\"{nameof(isStringRepresentationOfValue1EqualsToValue2)}\"={{1}}", isValue1EqualsToValue2, isStringRepresentationOfValue1EqualsToValue2);

I expected, that it should return:

"isValue1EqualsToValue2"=True;
"isStringRepresentationOfValue1EqualsToValue2"=True

but it returns:

"isValue1EqualsToValue2"=True;
"isStringRepresentationOfValue1EqualsToValue2"=False

Can you explain me is it expected behavior or it's a bug? If it's a bug, can you create issue for it?
It's reproduces on .NET 6.

[elgonzo]

Have you looked at the two strings generated by string.Format?
It's string.Format behaving as it should, since the decimal type preserves (up to 28) trailing fractional zeros.

Also see relevant documentation:

• format items in composite format strings without a formatString component: https://learn.microsoft.com/en-us/dotnet/standard/base-types/composite-formatting#format-string-component
• decimal: https://learn.microsoft.com/en-us/dotnet/fundamentals/runtime-libraries/system-decimal

[Maximys]

Yes, of course, I had looking at these two string. First is "10.0" and second is just "10".
Can you please quote lines from provided documentation, where I can read something like: "Two decimal values can be equal, but they string representation can be different"?

[elgonzo]

From the first link i posted (https://learn.microsoft.com/en-us/dotnet/standard/base-types/composite-formatting#format-string-component):

If formatString isn't specified, the general ("G") format specifier for a numeric, date and time, or enumeration type is used.

If the "G" format specifier is unfamiliar to you, look up the documentation about what the "G" format specifier does with respect to the numerical decimal type. Follow the respective links in the documentation, and you will land at https://learn.microsoft.com/en-us/dotnet/standard/base-types/standard-numeric-format-strings#general-format-specifier-g, which states about the "G" format specifier:

However, if the number is a Decimal and the precision specifier is omitted, fixed-point notation is always used and trailing zeros are preserved.

Additionally, from the second link i posted in my previous comment (https://learn.microsoft.com/en-us/dotnet/fundamentals/runtime-libraries/system-decimal):

Trailing zeros do not affect the value of a Decimal number in arithmetic or comparison operations. However, trailing zeros might be revealed by the ToString method if an appropriate format string is applied.

[colejohnson66]

Yes. However, the issue isn’t from string.Format, but decimal’s stringification code. 10m is stored internally as 10e0 (an integer of 10 and no exponent shift) whereas 10.0m is stored as 100e-1 (an integer of 100 and an exponent shift of -1). Unlike IEEE-754, decimal has no canonical storage requirements. You can see these bit differences with decimal.GetBits(10m) and decimal.GetBits(10.0m). This difference causes 10.0 to stringify with the extra zero. This has the benefit that decimal.Parse(someDecimalVariable.ToString()) gives back the same exact bit value (i.e., that is round trips). Not sure if that’s part of the spec, or if it’s just a quirk of the stringification code.

If you want to format values for your user interface, you should always use a format string.

Also, value equality does not imply string equality. Value equality means that the values represent the same thing. In numerics, 10 and 10.0 are the same thing, so they should compare equal. But that doesn’t mean they have the same bit representation. For example, double.NaN == double.NaN is false because NaNs are defined to be unequal even if the bit representation is the same. Equal values need not format the same, because they don’t have to. After all, double.NaN.ToString() == double.NaN.ToString() will be true despite their value forms being unequal. Essentially, bit/value equality implying string equality is not part of ToString’s requirements, so implementations can do what they want.