reprisal: mixed use of `na="null"` and `na="string"`

[r2evans]

Up front: you have discussed this many times, I think this discussion is slightly improved on those. It has come up in other packages as well. The issue is not whether JSON supports Inf or NaN, but tries to enable areas where [null,"Inf","NaN"] can in fact be meaningful.

• NA values not always translated to "null" #459 is not quite it, since that only address NA values.
• Lack of ways to set differently for infinite and NA numbers in R_num_to_char #445 is closer, but while it is correct that jsonlite::validate('[null,Infinity]') is not JSON, jsonlite::validate('[null,"Inf"]') is valid JSON.
• Support reading Javascript notation for special floating point values #302 is not right, since that was another suggestion to add Infinity literals, which is not valid JSON. I'm not suggesting that, I think sticking with "Inf" (etc) is good.
• "Inf" string as a value is being converted to numeric #245 is about converting from JSON, related.
• Documentation of na argument to toJSON is confusing #178 asked about "consistency in documentation" (about "Inf"), not about changing its behavior. And I'm not suggesting the behavior is inconsistent.

The closest of all the issues that mention Inf is #94, which argues a similar point as my request: NA and Inf are different. Some of your comments:

post-processing on the client seems inevitable

Yes, this assumes that either/both sides are aligned with this notion. Some of this already works:

fromJSON('[3.1415,null,"Inf","-Inf"]')
# [1] 3.1415     NA    Inf   -Inf    NaN

I think it is wise to stick with the default as.character behavior.

I may be misinterpreting your thought here. I think you're suggesting that the user can pre-process their own data to convert the vector/list so that Inf -> "Inf", etc. Unfortunately, on my naive attempts it presents a problem: either we force the vector to be a string vector (so numbers will be quoted), or we force it into a nested list.

x <- c(pi, NA, Inf, -Inf, NaN)
xout <- format(x, digits = 7)
xout[is.na(x)] <- "null"
xout[is.nan(x)] <- '"NaN"'
isinf <- is.infinite(x)
xout[isinf] <- ifelse(x[isinf] < 0, '"-Inf"', '"Inf"')
toJSON(xout)
# ["3.141593","null","\"Inf\"","\"-Inf\"","\"NaN\""] 

xout2 <- as.list(x) # same processing as above
toJSON(xout2)
# [[3.1416],["null"],["\"Inf\""],["\"-Inf\""],["\"NaN\""]] 

where neither is really a good approach as it mis-represents numbers or changes the apparent schema of the data, and they are far from the optimized performance jsonlite provides.

---

The fact that fromJSON('[3.1415,null,"Inf","-Inf","NaN"]') works is fairly compelling to me. While it's not safe to assume that "anything" that works into R should be something we can generate from R, but ... that array is about as simple an example where we should be able to create the valid JSON with a clear example.

I'm not suggesting we change any default values, clearly it's important to retain backward compatibility. I'm suggesting we allow another option to na= that supports the notion of null-or-"Inf".

I'm happy to work on the code if you are amenable to the discussion. I recognize you would then need to maintain that code, so it's important to me to make sure it is as minimal a change as possible with clear default behavior.