-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
assert: accept values with named types in InDelta*
, InEpsilon*
#1492
Comments
toFloat
converts types whose underlying type is a float64
toFloat
converts types whose underlying type is a int
, uint
or float
toFloat
converts types whose underlying type is a int
, uint
or float
toFloat
converts types whose underlying type is a int
, uint
or float
@RemiMattheyDoret This proposal looks good. However the existing type switch must be preserved (for speed) and the switch on Also: because this change will allow us to accept typed numbers in if reflect.TypeOf(expected).PkgPath() != "" {
IsType(t, expected, actual)
} Both changes must happen at the same time: if we introduce the toFloat change first, the type check applied later would be then a breaking change. As this change extends the behavior it will have to happen on a minor (not patch) release. |
Test case: https://go.dev/play/p/lGe4Y-2aBfz
So far all tests fail with "Parameters must be numerical". |
toFloat
converts types whose underlying type is a int
, uint
or float
InDelta*
, InEpsilon*
Issue
The function
toFloat
converts into afloat64
allint
,uint
andfloat
types. However,toFloat
does 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
/InEpsilon
for a type derived fromfloat64
.Question
Would it be desirable to allow
toFloat
to 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).
The text was updated successfully, but these errors were encountered: