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

Remove redundant vec implementations traits #4223

Closed
erickt opened this issue Dec 19, 2012 · 6 comments
Closed

Remove redundant vec implementations traits #4223

erickt opened this issue Dec 19, 2012 · 6 comments
Labels
C-cleanup Category: PRs that clean code up or issues documenting cleanup.

Comments

@erickt
Copy link
Contributor

erickt commented Dec 19, 2012

vec.rs has a couple redundant implementations of various traits that are needed until #4148 is fixed.

@nikomatsakis
Copy link
Contributor

Not critical for 0.6; removing milestone

@emberian
Copy link
Member

@erickt which redundant implements are you thinking of? I do not see any that are obvious, but I don't really understand #4148

@erickt
Copy link
Contributor Author

erickt commented Aug 3, 2013

@cmr: I'm having trouble remembering, to be honest. I think this was about the fact that we had to copy-paste implementations for ~[T], &[T], and @[T]. For example:

    impl<'self,T:Eq> Eq for &'self [T] {
        fn eq(&self, other: & &'self [T]) -> bool {
            self.len() == other.len() &&
                self.iter().zip(other.iter()).all(|(s,o)| *s == *o)
        }
        #[inline]
        fn ne(&self, other: & &'self [T]) -> bool { !self.eq(other) }
    }

    impl<T:Eq> Eq for ~[T] {
        #[inline]
        fn eq(&self, other: &~[T]) -> bool { self.as_slice() == *other }
        #[inline]
        fn ne(&self, other: &~[T]) -> bool { !self.eq(other) }
    }

    impl<T:Eq> Eq for @[T] {
        #[inline]
        fn eq(&self, other: &@[T]) -> bool { self.as_slice() == *other }
        #[inline]
        fn ne(&self, other: &@[T]) -> bool { !self.eq(other) }
    }

The reason we have to do this is that our handling of generic functions cannot automatically coerce a generic argument of type ~[T] to &[T], which means we need to have these multiple implementations. @nikomatsakis, do you remember if this is what we could clean up once #4148 is implemented?

@brson
Copy link
Contributor

brson commented Apr 21, 2014

Sounds like this is probably obsolete.

@thestinger
Copy link
Contributor

Agreed, this stuff will need to be redone as a whole. I have an issue open about generalizing it for Vec<T> and I think it will cover any redundancy like this.

@thestinger
Copy link
Contributor

#11876

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-cleanup Category: PRs that clean code up or issues documenting cleanup.
Projects
None yet
Development

No branches or pull requests

5 participants