Add {Try}GetBigIntegerValue to Utf8JsonReader

[ahsonkhan]

Split off from https://github.com/dotnet/corefx/issues/33320#issuecomment-437046345.

We already have the following "convert to .NET type" APIs on Utf8JsonReader:

public ref partial struct Utf8JsonReader
{
// These throw InvalidOperationException if there is a token type mismatch
    public string GetStringValue();
    public bool GetBooleanValue();

// These throw InvalidOperationException if there is a token type mismatch (i.e. not JsonTokenType.Number).
    public bool TryGetInt32Value(out int value);
    public bool TryGetInt64Value(out long value);
    public bool TryGetSingleValue(out float value);
    public bool TryGetDoubleValue(out double value);
    public bool TryGetDecimalValue(out decimal value);
}

Add the following:

public ref partial struct Utf8JsonReader
{
// This throws InvalidOperationException if there is a token type mismatch (i.e. not JsonTokenType.Number).
    public bool TryGetBigIntegerValue(out BigInteger value);

// This throw InvalidOperationException if there is a token type mismatch.
// This throw OverflowException if the number isn't an integer.
    public BigInteger GetBigIntegerValue();
}

[ahsonkhan]

@davidfowl, @JamesNK, is there a need for this API or can it be deferred to Future? If we need this API, what customer scenario does it enable?

[jkotas]

I do not think we should be making the new Utf8JsonReader depend on BigInteger.

If somebody needs to parse the input as BigInteger (or any other specialized type), they should be able to it themselves. We should add methods on BigInteger to make it easy and performant if necessary.

BTW: The current Utf8JsonReader.TryGetDecimalValue looks questionable to me. I would remove it. Decimal is specialized type. It should be on the same plan as BigInteger.

[AlexejLiebenthal]

I'm a bit on both sides:

Pro

• The user who needs to deal with numbers bigger than long.MaxValue, doesn't need to implement their own function
• As it is not explicitly forbidden in json to deal with huge numbers it shouldn't be in an API neither.
• Could it be useful in some context with big numbers like AI/ML, Security?

Cons

• This is specialized type in System.Numerics and adds a dependency to it (like @jkotas said)
• It is also not a built-in type like decimal (this is why decimal must be supported in my opinion)
• Could it also be converted by consumer, e.g. ExtensionMethod ({Try}GetBigInteger(this Utf8JsonReader reader{, out BigInteger value})?

I know decimal is also quite big and should nearly fit in any use case someone can imagine. Mostly I think this is used in finance context.
But: Maybe the number provided in a valid json file couldn't fit in decimal either. If supporting in this API the non built-in type BigInteger, shouldn't there also be a need for a BigDecimal.
In other words should C# like in Java also have an implementation of BigDecimal?

[jkotas]

built-in type like decimal

decimal is not a platform built-in type. It is pretty ordinary type. The only thing that make it a bit special is that C# language has lower-cased alias and support for decimal literals for historic reasons.

[AlexejLiebenthal]

I had this docs in mind: built-in types table
Could you please clarify this for me, what is or was (in netfx, netcore) the difference between System.Decimal <> decimal, System.Double <> double and System.Single <> float.

As I remember, when I needed to use once the BigInteger in a netfx project, I needed to add a reference to System.Numerics first. This is why I think, that decimal, which works in netfx and netcore projects out of the box, should also be supported directly by the API.
But I completely agree with you that decimal or Javas BigDecimal (something like an unbounded C# decimal) are very specialized types.

[jkotas]

the difference between System.Decimal <> decimal, System.Double <> double and System.Single <> float.

decimal, double and float are just C# language aliases for the System.Decimal, System.Double and System.Single types. They can be used interchangeably (in 99% contexts).

[AlexejLiebenthal]

I meant more the difference in historical manner. What has changed (in MSFT point of view) that you said:

The only thing that make it a bit special is that C# language has lower-cased alias and support for decimal literals for historic reasons.

Because for me float, double and decimal are the key types from which I can choose in C#, if I need a floating point representation. Than I decide how precise should it be and select one of them.

[jkotas]

The primary use for decimal type is counting money. A few of the C# designs were heavily influenced by enterprise needs. I was not on the team back then - but my guess is that's how the decimal gained the extra treatment in C#.

[ahsonkhan]

Deferring to future.

[layomia]

Triaged: a custom converter can be written for this at the serializer level. As @jkotas mentioned, the reader doesn't need this support. We can reopen this if needed. There is no support for BigInteger on the underlying Utf8Parser API. If enough usages of BigInteger show up in user models for deserialization, we can revisit it.