avoid type loss with JSON unmarshal/marshal

[grount]

issue #63

[knadh]

This is cool. Just need to figure out why the tests are failing: https://travis-ci.com/github/knadh/koanf/jobs/484967206

[grount]

See my latest commit, it seems that there were some issues.
Made a minor improvement as well.

• Ints should avoid calling Ints64s to avoid unneeded conversion between
  []in64 and []int.

• MergeAt unit test cannot be tested against JSON file since JSON treats
  numbers as float64 and confmap.Provider/YAML treats them as integers.

[knadh]

MergeAt unit test cannot be tested against JSON file since JSON treats numbers as float64 and confmap.Provider/YAML treats them as integers.

Does that mean Load()ing a JSON numeric array into an instance and then loading a YAML numeric array for the same key will fail? Merges should be seamless unless strict mode is on.

[grount]

With the current behavior, the latest loaded file will override the current type so I don't think it will be a problem.
It will make the strict mode a problem because loading [1,2,3] with JSON and YAML will fail even though they are the same.

Having said that:

• When loading JSON and then YAML, intArray: [1,2,3] -> the type is []int. Doing k.Float64s will fail.
• When loading YAML and then JSON, intArray: [1,2,3] -> the type is []float64. Doing k.Ints will fail.

This makes the behavior of getters somewhat inconsistent if someone loads multiple files and will try to get the value of an array.

With []int we can promote it to []float64 without loss, but doing []float64 to []int can cause a loss in case there is an actual float array [1.5,2.5,3.5] but in such case, in both usages, they should use k.Float64s and it should work.

WDYT?

[knadh]

When loading JSON and then YAML, intArray: [1,2,3] -> the type is []int. Doing k.Float64s will fail.

toFloat64() and toInt64() can handle this. For float -> int lossiness, it can just be documented, in case someone really wants to call Ints() on a known float array. The MustInt64s() (all the Must*) aliases could panic for these cases, but that might involve a bit of internal rewiring.

[grount]

It's possible to check if a []float64 includes only whole numbers to avoid data loss.
But the Must* functions will probably not work as intended, In MustInt64s when the user loaded [1.0,2.0,3.0] it should fail, but there is no way to know the intention since it could come either from the file or from the JSON.

[knadh]

Yep, checking for whole numbers will work. toFloat64() and toInt64() can return errors. These errors can be propagated in the Must*() getters and ignored in the others.

[grount]

I correct myself this is not an issue

When loading JSON and then YAML, intArray: [1,2,3] -> the type is []int. Doing k.Float64s will fail.
When loading YAML and then JSON, intArray: [1,2,3] -> the type is []float64. Doing k.Ints will fail.

Because toInt64 and toFloat64 try to cast at all cost using fmt.Sprintf and parsing, meaning no change in the existing behavior.

I think I will add another test of loading JSON and YAML and see that nothing is broken and you can merge it.

[knadh]

Looks good. @rhnvrm could you also please review?

[rhnvrm]

LGTM, one minor doc change.