[shounakjoshi88-a11y]

The float slice values rendered themselves with %f, which is six decimals:

func (s *float64SliceValue) String() string {
	out := make([]string, len(*s.value))
	for i, d := range *s.value {
		out[i] = fmt.Sprintf("%f", d)
	}
	return "[" + strings.Join(out, ",") + "]"
}

and the accessors re-parse that rendering (getFlagType reads Value.String() and runs it through the converter), so GetFloat64Slice returned values that had lost their precision:

--f64s=1e-7,0.1,123456789.123456789,5e-324

binds [1e-07 0.1 1.2345678912345679e+08 5e-324], but GetFloat64Slice returned [0 0.1 1.23456789123457e+08 0].

Every other numeric kind renders itself with strconv.Format* and the precision -1 (float64Value uses strconv.FormatFloat(float64(*f), 'g', -1, 64)), so the float slices do the same now. GetFloat32Slice had the same fault and is fixed with it.

The new test in float64_slice_test.go parses a flag with more digits than %f keeps and compares the accessor with the bound variable. It fails without the change:

--- FAIL: TestF64SKeepsEveryDigit
    float64_slice_test.go:43: expected f64s[0] to be 1e-07 but got: 0 from GetFloat64Slice
    float64_slice_test.go:43: expected f64s[2] to be 1.2345678912345679e+08 but got: 1.23456789123457e+08 from GetFloat64Slice
    float64_slice_test.go:43: expected f64s[3] to be 5e-324 but got: 0 from GetFloat64Slice

and passes with it.

$ go test ./...
ok  	github.com/spf13/pflag	2.291s

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[shounakjoshi88-a11y]

The CI workflow on this pull request is in action_required, which needs a maintainer to approve it before it can run on a fork pull request. If you approve it, it should pass - the same commands run green locally:

$ go test ./...
ok  	github.com/spf13/pflag	2.291s

gofmt reports nothing on the three changed files.

The new test fails on the unmodified tree:

--- FAIL: TestF64SKeepsEveryDigit
    float64_slice_test.go:43: expected f64s[0] to be 1e-07 but got: 0 from GetFloat64Slice
    float64_slice_test.go:43: expected f64s[2] to be 1.2345678912345679e+08 but got: 1.23456789123457e+08 from GetFloat64Slice
    float64_slice_test.go:43: expected f64s[3] to be 5e-324 but got: 0 from GetFloat64Slice

and passes with the change.