v10: De-serialization of Decimal fails when there is no leading zero

[Richard-Payne]

Source/destination types

Source: string
Dest: Decimal

Source/destination JSON

source: ".1"
dest: 0.1

Expected behavior

Expect num = 0.1

Actual behavior

Newtonsoft.Json.JsonReaderException: Input string '.1' is not a valid decimal

Steps to reproduce

var num = JsonConvert.DeserializeObject(".1", typeof(Decimal));

Works fine with v9 but fails in v10.

[JonHanna]

.1 is not a valid JSON representation of a number. The period must be preceded by either a single 0 or by a digit in the range 1–9 followed by zero or more digits.

[Richard-Payne]

ok, but it worked in the prior versions. I entirely understand making the serializer output correct JSON but limiting the deserializer in this way means that any stored data is now broken.

Also, incidentally, if you change Decimal to Double then it still works fine with ".1"

[JonHanna]

Ahh, if it used to work then it should probably accept such invalid input as long as it doesn't cause it to somehow do the wrong thing on valid input.

[TylerBrinkley]

See here for a discussion of this when the optimized double parsing was in the works for Json.NET 10.0 which was then rolled back due to double precision issues when parsing. The same parsing logic was used in the optimized decimal parsing PR for Json.NET 10.0 which has not been rolled back.

[AlexisColes]

Just to be clear, we are sacrificing backwards compatibility for speed with v10 and there is no plan to make this work as it used to in v9?

So we need to to change our code to deal with this before we upgrade to 10+

[TylerBrinkley]

To quote @JamesNK

I want the new method to reject those as invalid. The only place that this parser will be used is JsonTextReader and the spec requires that doubles follow an exact format. That Json.NET accepted them before was a bug.

The parser could easily be updated to accept leading periods and maintain the performance improvements but it was considered a bug by James that it supported parsing those values before. Yes, you'll need to change your code to deal with this before you upgrade to 10+ perhaps by just reading in the json and immediately writing it back out which should fix the formatting.

[Richard-Payne]

It's not just code though. Any serialized, persisted data will now by broken too.

Yes, you'll need to change your code to deal with this before you upgrade to 10+ perhaps by just reading in the json and immediately writing it back out which should fix the formatting.

So every application out there has to be slowed down with unnecessary writes just so the library can remain "pure". And that's not to mention the huge amount of work involved in implementing those write backs and testing to ensure that we've caught them all.

I agree with James, it is a bug, but breaking behaviour which has been around for a long time is bad. If there were a significant performance hit in supporting the "wrong" way then I could maybe see it but if, as you say, support is inexpensive performance wise then why break anything?

[TylerBrinkley]

I agree with you but that wasn't my call.

[JamesNK]

Hmmm, I'm torn on one vs the other. You really shouldn't have number values that start with a decimal point - they won't work with any other JSON framework - but on the other hand it isn't difficult to parse those values.

[Richard-Payne]

Are there any other frameworks these days? Your's is pretty much the de facto standard. ;-)

[AlexisColes]

Maybe we could have strict setting that we could set to false.

[wallymathieu]

@Richard-Payne there are a couple of JSON frameworks out there.
I've used the following (besides Newtonsoft.Json):

• DataContractJsonSerializer
• System.Json
• FSharp.Data contains a parser and serializer
• Fleece is focused on f# and wraps other JSON implementations (like Newtonsoft.Json)
• Chiron is focused on f#, but contains a JSON parser (it's originally based on Fleece)

And there are additional new Json implementations:

• SpanJson
• Utf8Json
  et.c.

[Richard-Payne]

@JamesNK did this ever get looked at?