Skip to content
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

Derive more for structs #544

Closed
Susurrus opened this issue Feb 28, 2017 · 5 comments
Closed

Derive more for structs #544

Susurrus opened this issue Feb 28, 2017 · 5 comments

Comments

@Susurrus
Copy link
Contributor

Susurrus commented Feb 28, 2017

I'd like to propose adding #[derive(Copy, Debug, Eq, PartialEq)] for some of the structs here in libc so they can be used downstream. This may be controversial for various reasons, but I have a specific use case for Eq and Debug on the termios struct. Additionally Clone may be worth adding also, though I don't know if that could blanket apply to all structs.

@alexcrichton
Copy link
Member

Debug is covered by #302 and otherwise Eq/PartialEq are left out for compile time implications. The Clone/Copy traits are already implemented for all structs.

I think we'd require an RFC for Eq/PartialEq, so I'm going to close this in favor of #302

@Susurrus
Copy link
Contributor Author

Susurrus commented Mar 7, 2017

@alexcrichton Is that an RFC as in the repo rust-lang/rfcs? I'll post on internals as a pre-RFC to get some thoughts together before I try to go down that road. I wanted to ask though, why do you think deriving Eq and PartialEq will require an RFC, is it that big of a change?

@alexcrichton
Copy link
Member

Yeah in rust-lang/rfcs.

I personally would be against such behavior as it doesn't make sense for most types and it also has serious compile-time implications. The very few niches which require it would end up imposing a cost on all other users by increasing the compile time of this crate (b/c of so many more impls)

@Susurrus
Copy link
Contributor Author

Susurrus commented Mar 8, 2017

What about including it with #302, which I wasn't sure if you meant to suggest that earlier.

@alexcrichton
Copy link
Member

Yes having it optional off-by-default is plausible, but I'd still want to measure the impact.

danielverkamp pushed a commit to danielverkamp/libc that referenced this issue Apr 28, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants