-
Notifications
You must be signed in to change notification settings - Fork 3
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
Restructure and slightly refactor code #13
Conversation
See rust-lang/rust-clippy#9271, this is a bug in clippy
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.
Looks good for the most part, just a few questions
@@ -1,3 +1,7 @@ | |||
#![allow(clippy::cast_possible_wrap)] | |||
#![allow(clippy::cast_precision_loss)] | |||
#![allow(clippy::cast_sign_loss)] |
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.
Why do these need to be added?
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.
powf
has some code that causes clippy warnings. For example x.to_bits() as i32
can wrap. If you want, i can go further into it, but IMO the warnings indicate problems that either can't happen with our assumptions or don't matter (wrapping doesn't matter because we're just using the value for bitwise operations).
I tried "cleaning up" a bit. Mostly by moving code out of
lib.rs
. It's now just the tests and some re-exporting from the new modules.List of changes:
FullTypeName
->Self
where applicable)rustfmt
into_data()
function that "consumes" self to return the dataVec<[f32; 3]>
. This is A) needed to implement the conversion functions withoutpub(crate)
and B) can also be used by API users, which is a neat solution IMHOAltogether, this changes the internal structure a bit but doesn't really touch the public API. You can technically access things like
yuvxyb::rgb_xyb::linear_rgb_to_xyb
at the moment (which would be impossible after this change), but I'd consider those functions to be internal so this is only a "kind of breaking" change IMO.