string.Format Works incorrectly or Inconsistently .net Framework vs .netCore vs Learn Article

[ECartman]

Description

https://referencesource.microsoft.com/#mscorlib/system/text/stringbuilder.cs,2c3b4c2e7c43f5a4

internal StringBuilder AppendFormatHelper

vs

internal void AppendFormatHelper

vs

https://learn.microsoft.com/en-us/dotnet/standard/base-types/composite-formatting#escaping-braces

according to the article: The way escaped braces are interpreted can lead to unexpected results. For example, consider the format item {{{0:D}}}, which is intended to display an opening brace, a numeric value formatted as a decimal number, and a closing brace. However, the format item is interpreted in the following manner:

The first two opening braces ({{) are escaped and yield one opening brace.
The next three characters ({0:) are interpreted as the start of a format item.
The next character (D) would be interpreted as the Decimal standard numeric format specifier, but the next two escaped braces (}}) yield a single brace. Because the resulting string (D}) isn't a standard numeric format specifier, the resulting string is interpreted as a custom format string that means display the literal string D}.
The last brace (}) is interpreted as the end of the format item.
The final result that's displayed is the literal string, {D}. The numeric value that was to be formatted isn't displayed.

this is inconsistent. on C# Core. we can note that the Token is consumed before the the "Literal" is parsed. on C# Framework (4.8) it does what the Article says.

so which one is it ?

in Our opinion. it SHOULD do what C# Core does. and this is a C# framework BUG. if it is. therefore it should be fixed on C# framework (4.xx+) it is not. C# Core should... work consistently vs C# framework does. that make no logical sense. if Both Approaches are "right" (i dunno how that would be... but whatever) technically. therefore. the Article on MSDN should split one version for .net 4.8 and another for .NET Core.

Reproduction Steps

C# Core 6.0:

Console.WriteLine(string.Format("{{Greeting={0}, YourHex=0x{1:x}}}", "hola", 02123554));
Console.ReadLine();

Output: {Greeting=hola, YourHex=0x206722} C# Framework:

using System;
    internal class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine(string.Format("{{Greeting={0}, YourHex=0x{1:x}}}", "hola", 02123554));
            Console.ReadLine();
        }
    }

Output: {Greeting=hola, YourHex=0xx} The correct output IMO is the C# core.

Expected behavior

on all Run-time's to have a consistent output.
OR: correct the MSDN/LEARN documentation so it becomes Uniform and Informs developers of the problem. on Framework and Tells Core users the Error does not happens on Core.

(Code change required would be a back-port or edit of the function AppendFormatHelper as described on the Description.

Actual behavior

Inconsistent output. Miss-leading Documentation.

Regression?

Did this work in a previous build or release of .NET Core, or from .NET Framework? YES! that is the point. :)

If you can try a previous release or build to find out, that can help us narrow down the problem: see the previous data.

If you don't know, that's OK, oh I do known.

Known Workarounds

add spaces so "}}" does not get changed as a literal "}"

Configuration

.NET Framework 4.8 .NET Core 6.0

Other information

there is a Pun About. PERL and Regular Expressions. but... I lost it.

[stephentoub]

This was a bug fix in .NET Core 3.0: https://github.com/dotnet/runtime/issues/28649 The .NET Core behavior is by design.

[ECartman]

hence should this be brought to MSDN/Learn because, the documentation is not accurate. and it IS an issue in .net 4.8 or will it not be back-ported or fixed on 4.8?

[stephentoub]

There are no plans to fix this in .NET Framework 4.8.

[ECartman]

Alright. I will check with MSDN/LEARN folks then to upgrade the Document to Provide Accurate Information then. because as it stands is Incorrect/Inconsistent. thanks for the Ref # on the change.

side note. its shameful we have such outdated information. should also had open a Request to update Documentation back in 2019, We are at Microsoft. almost 4 Years. and the document is outdated.. wow.