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

Deriving may want to ignore marker fields #726

Closed
steveklabnik opened this issue Jan 23, 2015 · 1 comment
Closed

Deriving may want to ignore marker fields #726

steveklabnik opened this issue Jan 23, 2015 · 1 comment
Labels
T-lang Relevant to the language team, which will review and decide on the RFC. T-libs-api Relevant to the library API team, which will review and decide on the RFC.

Comments

@steveklabnik
Copy link
Member

Issue by kballard
Sunday May 18, 2014 at 00:05 GMT

For earlier discussion, see rust-lang/rust#14268

This issue was labelled with: in the Rust repository


Marker fields are used to provide extra information about types, including opting out of Copy, Send, and Share bounds. However, the presence of a marker field can prevent the ability to #[derive] traits for that type. For example, core::kinds::marker::NoCopy only implements Clone and Eq (according to rustdoc; I am unsure if there are any libstd traits it implements because rustdoc doesn't show cross-crate traits). This means that any struct with a NoCopy field cannot e.g. derive Show, or Ord, or other useful traits.

I think the right solution here is to simply not consider the marker fields when deriving traits, with the only exception being Clone. Every other trait should just pretend that field doesn't exist.

@petrochenkov petrochenkov added T-lang Relevant to the language team, which will review and decide on the RFC. T-libs-api Relevant to the library API team, which will review and decide on the RFC. labels Jan 28, 2018
@Centril
Copy link
Contributor

Centril commented Oct 7, 2018

I don't think this applies anymore / is not actionable so I am closing this.

@Centril Centril closed this as completed Oct 7, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T-lang Relevant to the language team, which will review and decide on the RFC. T-libs-api Relevant to the library API team, which will review and decide on the RFC.
Projects
None yet
Development

No branches or pull requests

3 participants