-
Notifications
You must be signed in to change notification settings - Fork 96
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
Added ability to create and edit color tables. #314
Conversation
44e6137
to
00d69f7
Compare
00d69f7
to
df79fbb
Compare
an existing file, which seems to have race-condition issues on Linux.
Co-authored-by: Laurențiu Nicola <[email protected]>
end_index: u8, | ||
end_color: &ColorEntry, | ||
) -> Result<ColorTable<'a>> { | ||
if start_color.palette_interpretation() != end_color.palette_interpretation() { |
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 might be wrong, but it feels like this might just as well be an assert_eq!
, since it's a user error to pass in different types of entries.
But it's fine to leave it like this, if there's prior art or you think it's more user-friendly.
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 lean toward not panic!
-ing on behalf of the user whenever possible. If they want to unwrap
and get a panic!
that's their business, but rather give them the option to handle it more gracefully if they want.
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.
What I would have rather done is make it a compile error :) But that's a rabbit hole.
Co-authored-by: Laurențiu Nicola <[email protected]>
bors r=lnicola |
Build succeeded: |
CHANGES.md
if knowledge of this change could be valuable to users.