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]

SmartFormat.NET

[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"

If it is only about different output for "null or empty" and other values, the ConditionalFormatter may be more handy:

Smart.Format("{0:cond:{} |is null or empty}", "");
// Result: "is null or empty"

[sygmond]

Thanks for the solution. It works but it looks more like a workaround and kind of clouds the code if you have to use it multiple times.
As far as I've seen, PluralLocalizationFormatter take always a number. That means if the value is a string, it should not kick in.

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

Using it like this should probably not be possible as 1234 is value type and not a nullable/reference, so it should not print "null" or "empty".

These two lines tells me that both the string and the number are treated the same when most probably they shouldn't.

// 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"

I see this more as a bug, because a string like "1234" should be ignored by PluralLocalizationFormatter.

[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;