You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'd like to implement a trait in terms of a few other ones, but the compiler tells me that I have conflicting trait implementations. The most succinct example is
Now, if there existed a type implementing both SpecificOne and SpecificTwo, that would be a problem, but there isn't.
I'm pretty sure the compiler should be able to determine whether the implementation is legal or not. (It's not clear to me whether you have to worry about something introducing ambiguities by linking to your crate later.) And unless I'm overlooking something (not to imply that this is unlikely), it seems to me that this is an important thing to be able to do.
My specific use case is for SHA1 hashing of things. I want to do something along the lines of:
trait Hashable { fn hash (&self, Sha1 sha); }
impl<T: to_bytes::IterBytes> T: Hashable { /* send the bytes to the sha1 */ }
impl<T: io::Reader> T: Hashable { /* send the stream to the sha1 */ }
Readers can't be IterBytes because the bytes iterator function is defined as being pure.
The text was updated successfully, but these errors were encountered:
I had been reading the tutorial and didn't catch anything saying that you can provide an impl for a bare trait in this way, and the people that I briefly consulted on IRC didn't immediately come up with this, so maybe that's something that should be added to, or made more prominent in, the tutorial.
…1995
Improvements for `type_repetition_in_bounds` lint
Some improvements for `type_repetition_in_bounds`:
- add a configurable threshold to trigger the lint (rust-lang#4380). The lint won't trigger anymore if there are more bounds (strictly) than `conf.max_trait_bounds` on this type.
- take generic args into account over bounded type (rust-lang#4323)
- don't lint for predicates generated in macros (rust-lang#4326)
Fixesrust-lang#4380,
Fixesrust-lang#4323,
Fixesrust-lang#4326,
Closesrust-lang#3764
changelog: Fix multiple FPs in `type_repetition_in_bounds` and add a configuration option
Note: the rust-lang#3764 has already been fixed but not closed
I'd like to implement a trait in terms of a few other ones, but the compiler tells me that I have conflicting trait implementations. The most succinct example is
Now, if there existed a type implementing both SpecificOne and SpecificTwo, that would be a problem, but there isn't.
I'm pretty sure the compiler should be able to determine whether the implementation is legal or not. (It's not clear to me whether you have to worry about something introducing ambiguities by linking to your crate later.) And unless I'm overlooking something (not to imply that this is unlikely), it seems to me that this is an important thing to be able to do.
My specific use case is for SHA1 hashing of things. I want to do something along the lines of:
Readers can't be IterBytes because the bytes iterator function is defined as being pure.
The text was updated successfully, but these errors were encountered: