Reading NaN and Inf

[c42f]

We've got some external non-julia code producing JSON, with some Float64 values which happen to be NaN. We can produce null for these, but it's unfortunate that they then can't be distinguished from Inf.

This has been discussed before - see #75 and #56 (comment) but it would be nice to have the option for strict vs flexible handling of NaN and Inf (for example the way that the latest RapidJson does this is to use a writer flag)

Is there any interest in supporting this kind of thing? Would a PR be likely to be accepted?

CC @janzill

[TotalVerb]

Instead of a writer flag, see also #165. I'm sorry I've let #162 sit for a while; I'll have some time later this week to finish it and get an early implementation of #165 in (pending review, of course).

[TotalVerb]

Also, to fully support this, we'll need a reader equivalent to the writer context. That shouldn't be to difficult, but suggestions for a good interface are welcome.

[TotalVerb]

To be clear, I am heavily opposed to having this implementation in this package, not least because what you propose is not valid JSON. But I believe the changes I outlined above should make it easy to create a JSON like serialization format, reusing much of the JSON infrastructure.

[c42f]

I hope it's clear that this issue is more of a question than a carefully considered proposal.

However, having the ability to parse and generate json-like variants would be extremely helpful, particularly when trying to parse something malformed from an external service you can't control. When things like python's json.dumps emit NaN and Infinity (by default!?) there's going to be plenty of this in the wild.

#165 looks quite interesting from this point of view, and I'd also love to see a reader version of the proposed writer context. It would be great if the only customization I needed would be to override something like show_json(::MySerialization, ::AbstractFloat) to allow printing of NaN (or, obviously, the equivalent reader version of the same).

[TotalVerb]

Great, thanks for the feedback. I think your proposed interface is really nice, and should be possible.

[TotalVerb]

@c42f #162 is now open for review! It would be greatly appreciated if you could take a look. An implementation of NaN and Inf being dumped directly is in the tests.