Skip to content

Add Clone+Debug derives to vte::Parser #143

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.

Sign up for GitHub

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

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Add Clone+Debug derives to vte::Parser #143

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion src/lib.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -52,7 +52,7 @@ const MAX_OSC_RAW: usize = 1024;
///
/// Generic over the value for the size of the raw Operating System Command
/// buffer. Only used when the `std` feature is not enabled.
#[derive(Default)]
#[derive(Debug, Default, Clone)]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should implement all the standard traits that are useful to potential consumers:
https://rust-lang.github.io/api-guidelines/interoperability.html#types-eagerly-implement-common-traits-c-common-traits

I think eq/clone would probably be useful for testing. Ord/Hash shouldn't be necessary.

Debug doesn't seem relevant, I don't see how we'd provide a useful debug implementation for it that doesn't just dump a bunch of internal state that can change at any time.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nobody should be expecting Debug information to be a reliable API. It's more for... well, debugging. Which I do think "leaking" internal state is perfectly reasonable to do. If we can clean up the format to be more useful, then that's great, but I don't see an issue with the derived one personally.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Which I do think "leaking" internal state is perfectly reasonable to do.

That internal state has no information that is of use to consumers though and none of it is accessible to them in any other way. It's basically just arbitrary data that has no clear meaning to library users. Littering that out to a debug implementation doesn't help anyone.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suppose I see what you mean.

It may be worth putting a little thought into what might actually be useful to users while debugging their use of the parser tho. Like how far into a sequence they are, state machine information, etc.

pub struct Parser<const OSC_RAW_BUF_SIZE: usize = MAX_OSC_RAW> {
state: State,
intermediates: [u8; MAX_INTERMEDIATES],
Expand Down
2 changes: 1 addition & 1 deletion src/params.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,7 @@ use core::fmt::{self, Debug, Formatter};

pub(crate) const MAX_PARAMS: usize = 32;

#[derive(Default)]
#[derive(Default, Clone)]
pub struct Params {
/// Number of subparameters for each parameter.
///
Expand Down