Different output for a number, a string, an empty string and null

[sygmond]

If the value of a string is a number, i.e. 1234, the parsing will take it as null or empty. When adding any extra letter(s) i.e. 1234extra, the parsing is done correctly.

Smart.Format version: 3.2.0 (throws exception) and 3.2.1

Framework version: net 6.0, net 7.0

• A working source code example to reproduce the bug:

using System;
using SmartFormat;

class Program
{
    static void Main()
    {
        string line1 = Smart.Format("Number: {0:{} |is null or empty}", "1234");
	string line2 = Smart.Format("Number: {0:{} |is null or empty}", "1234extra");

        Console.WriteLine(line1);
	Console.WriteLine(line2);
    }
}

• The current result: An exception on version 3.2.0 and empty value on version 3.2.1:

Number: is null or empty
Number: 1234extra 

• Expected result: The string value: 1234
• Full exception details (version 3.2.0):

Unhandled exception. SmartFormat.Core.Formatting.FormattingException: Error parsing format string: The input string '1234extra' was not in a correct format. at 11
Number: {0:{} |is null or empty}
-----------^
 ---> System.FormatException: The input string '1234extra' was not in a correct format.
   at System.Number.ThrowOverflowOrFormatException(ParsingStatus status, ReadOnlySpan`1 value, TypeCode type)
   at System.Convert.ToDecimal(String value, IFormatProvider provider)
   at SmartFormat.Extensions.PluralLocalizationFormatter.TryEvaluateFormat(IFormattingInfo formattingInfo)
   at SmartFormat.SmartFormatter.InvokeFormatterExtensions(FormattingInfo formattingInfo)
   at SmartFormat.SmartFormatter.EvaluateFormatters(FormattingInfo formattingInfo)
   at SmartFormat.SmartFormatter.Format(FormattingInfo formattingInfo)
   --- End of inner exception stack trace ---
   at SmartFormat.SmartFormatter.FormatError(FormatItem errorItem, Exception innerException, Int32 startIndex, IFormattingInfo formattingInfo)
   at SmartFormat.SmartFormatter.Format(FormattingInfo formattingInfo)
   at SmartFormat.SmartFormatter.Format(FormatDetails formatDetails, Format format, Object current)
   at SmartFormat.SmartFormatter.Format(IFormatProvider provider, String format, IList`1 args)
   at SmartFormat.SmartFormatter.Format(String format, Object[] args)
   at SmartFormat.Smart.Format(String format, Object arg0)
   at Program.Main()

• Workaround: Adding a letter/word after the string number seems to "fix" it but that's kind of unacceptable
• Version in which it works: 3.1.0 and lower

[axunonb]

Are you using the SmartFormat.NET or the SmartFormat package?
In both cases: are you using the default extensions?

[axunonb]

The issue as described does not go back to the Parser, but to the IFormatters.

The format string in the example will auto-select the formatter (implicitly).
So the answer the question above is still relevant.
In your case, it looks like the PluralLocalizationFormatter kicks in, which leads to the results as described.
If anything in the output is not as expected, it's always recommended to to use a named formatter.

In order to distinguish null, string.Empty, or a another value, the best way is:

// Explicitly let the ChooseFormatter do the job
Smart.Format("{0:choose(null|):null|empty|{}}", 1234); 
// Result: "1234"
Smart.Format("{0:choose(null|):null|empty|{}}", "1234"); 
// Result: "1234"
Smart.Format("{0:choose(null|):null|empty|{}}", ""); 
// Result: "empty"
Smart.Format("{0:choose(null|):null|empty|{}}", default(object?)); 
// Result: "null"

[axunonb]

Are you using the SmartFormat.NET or the SmartFormat package? In both cases: are you using the default extensions?

The link to the dotnetfiddle answers the question.

The change introduced in v3.2.0 was not intentional.
To come back to the v3.1.0 behavior, you could also write
Smart.Default.GetFormatterExtension<PluralLocalizationFormatter>()!.CanAutoDetect = false;