Use github.com/shopspring/decimal

[joefitzgerald]

Rationale: https://github.com/shopspring/decimal#why-dont-you-just-use-float64

Using float64 to handle decimal values can lead to unexpected outcomes. If you're open to this, I would be happy to open a PR for it.

[adlio]

What's the use case where a float64 issue can occur now? Users of this package are free to take the float64 and wrap it in a decimal type if they need to do math on it. The package itself doesn't do any mathematical operations (at least none that I can think of).

I had wanted to use a Decimal type instead of float64, but didn't want to introduce dependencies just for their types. Golang #12127 suggests we may eventually get stdlib support for decimals, and lists a few contenders for the model (including shopspring/decimal). Without a resolution there, I don't want to change types in a backwards incompatible ways.

I'd be open to a pull request that adds a second accessor for a shopspring/decimal for the places you'd want one added.

[axgfn]

Why not just use json.Number? Then users can convert it to whichever number type they like.

This is what I did in my own ad-hoc Harvest API package.

[axgfn]

Users of this package are free to take the float64 and wrap it in a decimal type if they need to do math on it.

This is really not a good strategy for dealing with monetary values because the conversion itself may introduce errors before any calculation even occurs.