Issue
The function toFloat converts into a float64 all int, uint and float types. However, toFloat does not support conversion from a type whose underlying type is one of those accepted types. Consider for example
type f float64
value, ok := toFloat(f(1.2)) // returns 0.0, false
and therefore some assertions may fail such as
var (
expected f = 1.1
actual f = 1.1
)
assert.InEpsilon(t, expected, actual, 1e-12)
who fails with message Parameters must be numerical. The user is then forced to cast the input values
assert.InEpsilon(t, float64(expected), float64(actual), 1e-12)
⁉️ Note that this is particularly problematic that testifylint enforces to use InDelta/InEpsilon for a type derived from float64.
Question
Would it be desirable to allow toFloat to recognise types derived from any of the currently accepted types?
Suggestion
func toFloat(x interface{}) (float64, bool) {
var xf float64
xok := true
switch reflect.TypeOf(x).Kind() {
case reflect.Int, reflect.Int8, reflect.Int16, reflect.Int32, reflect.Int64:
xf = float64(reflect.ValueOf(x).Int())
case reflect.Uint, reflect.Uint16, reflect.Uint32, reflect.Uint64:
xf = float64(reflect.ValueOf(x).Uint())
case reflect.Float32, reflect.Float64:
xf = reflect.ValueOf(x).Float()
default:
xok = false
}
return xf, xok
}
Consideration
Performance must be considered. Two successive switch-case blocks (the first one not using reflection) may be of interest to retain high performance for cases where the type received is directly numerical (and not just derived from a numerical type).
Issue
The function
toFloatconverts into afloat64allint,uintandfloattypes. However,toFloatdoes not support conversion from a type whose underlying type is one of those accepted types. Consider for exampleand therefore some assertions may fail such as
who fails with message
Parameters must be numerical. The user is then forced to cast the input valuesInDelta/InEpsilonfor a type derived fromfloat64.Question
Would it be desirable to allow
toFloatto recognise types derived from any of the currently accepted types?Suggestion
Consideration
Performance must be considered. Two successive switch-case blocks (the first one not using reflection) may be of interest to retain high performance for cases where the type received is directly numerical (and not just derived from a numerical type).