Remove the .to[X] converters

[mdedetrich]

Currently scalajson has various .to[X] i.e. .to[BigDecimal] converters, mainly used by JNumber. Over time I have been forming the opinion that they should be removed, reasons are

• I don't think anyone uses them
• You can still expose "unsafe" conversions (i.e. .to[BigDecimal] on a number with a really big exponent, issue with some libraries that really value correctness, i.e. circe Integration with ScalaJSON circe/circe#690 (comment))
• Their implementation is not trivial (i.e. instead of a form of typeclass should we just define methods within JNumber?). The AST is designed to be trivial as possible
• Other libraries using ScalaJSON AST will probably want their own interface for exposing the number conversions

Any objections?

[travisbrown]

I'm 👍 on this—as I've noted before, this piece of ScalaJSON seems to be mixing decoding concerns in a project that's otherwise (usefully) focused solely on providing a JSON representation.

[ktoso]

+1, same reasoning as @travisbrown - let this lib be as focused on "just-the-representation" as possible.

[Ichoran]

I have a contrary view. There are very few possible correct ways to convert a JSON number into some other representation, and it's often hard to do it right. If you don't do it for people, they'll do it wrong and things will break, and not because they wanted different behavior. There isn't any other sensible behavior; it's numbers! Thus, the AST should handle the conversions to common types.

It shouldn't do this in ways that are difficult to make reliable and/or performant (e.g. there should not only be methods that throw exceptions if things are out of range), but it should do them.

In cases where there are a variety of plausibly correct ways to do things, then the AST should remain agnostic. This is not one of those cases.

[mdedetrich]

@Ichoran I have removed the the .to converters, however I think the biggest issue with them is the API (i.e. along with the .to) methods. Also the converters that were old didn't deal with the issues you were talking about in regards to converting numbers outside of ranges and correctness.

I am open to adding them back in, along with the following design decisions

1. They are direct members of JNumber and not using a typeclass like .to
2. The methods are named .toDouble/toInt etc etc
3. They don't through exceptions for things like out of range, i.e. some of the conversions will be Option[X]. This should also be documented (i.e. should a toInt truncate if its not a whole number, or should it return None, should toDouble return None if we lose precision? These questions need to be answered).
4. Maybe we should add helper methods like def isWholeNumber (in tandem with point 3)

The current implementation didn't do any of these

If someone can submit a PR that does this, I would be happy to include it if it follows the above points.

We have some inspiration from argonaut here https://github.com/argonaut-io/argonaut/blob/master/argonaut/shared/src/main/scala/argonaut/JsonNumber.scala to do this.