-
Notifications
You must be signed in to change notification settings - Fork 15
Refactor inverse_eltype
calculations to use types.
#137
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
base: master
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll review in more detail later today or tomorrow. Generally, it looks fine but this is a breaking change (inverse_eltype
is part of the documented interface and with this PR inverse_eltype
of TransformTuple
etc call the definition with types which mostly likely downstream packages do not define currently and hence will throw an error).
Yes, of course it is a breaking change. That's why I released 1.0.0 yesterday, instead of relying on "you can break everything in 0.x". Among registered packages, the following are affected because they define a method (based on dependents list and code search):
If we release 2.0.0, we might as well fix #66 since that is breaking too. |
Co-authored-by: David Widmann <[email protected]>
Co-authored-by: David Widmann <[email protected]>
This is a continuation of #133 in a sense, using the approach to fix some other issues.
Incidental changes:
inverse(::VectorTransfrom, x)
return a vector of floats #133 and place in utilities.jl