Joseph Musser
Joseph Musser
😃 huge win with #54. Total assembly resolve time is 964 ms (version 1.0.0-alpha.99.g7d2f4a388d):  Where alpha.97 took 8328 ms:  Total time is now 17.4 seconds: 
From the perspective of someone who has consumed the C# spec proposals as a library and tooling author, this spec documentation is well worth solving and delivering along with each...
Does that mean the recently-created https://docs.microsoft.com/en-us/dotnet/fundamentals/code-analysis/quality-rules/ca1834 is now obsolete, or is StringBuilder itself still slower? 
This makes sense to me since we already do `\r`, `\n`, `\t`, `\v`, `\a`, `\0`, and `\\`. (We missed `\"`, I guess? 😄) Would we simply use the `\u` representation...
What if we leave the display as-is and call out the mismatching numeric `char` values no matter what they are?