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

Move SliceIndex type parameter to parameters #3483

Open
SOF3 opened this issue Sep 5, 2023 · 2 comments
Open

Move SliceIndex type parameter to parameters #3483

SOF3 opened this issue Sep 5, 2023 · 2 comments

Comments

@SOF3
Copy link

SOF3 commented Sep 5, 2023

If I have a struct like this:

struct T1 {}
struct T2 {}

pub struct Aggregate {
    v1: Vec<T1>,
    v2: Vec<T2>,
}

impl Aggregate {
    pub fn compute<R>(&self, range: R) -> Option<u32> {
        for v in self.v1.get(range)? {
            output += v.compute();
        }
        for v in self.v2.get(range)? {
            output += v.compute();
        }
        Some(output)
    }
}

The type bound for R would need to be R: SliceIndex<[T1]> + SliceIndex<[T2]>, which exposes internal implementation details.

I propose moving the <T> in SliceIndex<T> to the methods and leverage GATs:

trait SliceIndex : Sized {
    type Output<T: ?Sized>: ?Sized;
    fn get<T: ?Sized>(self, slice: &T) -> Option<&Self::Output<T>>;
    fn get_mut<T: ?Sized>(self, slice: &mut T) -> Option<&mut Self::Output<T>>;
    // ...
}
@shepmaster
Copy link
Member

How could you remove the type parameter without breaking backwards compatibility? This compiles on stable:

fn it_is_stable(_: impl std::slice::SliceIndex<i32>) {}

@SOF3
Copy link
Author

SOF3 commented Sep 5, 2023

Currently the trait is sealed, so the usage pattern is quite limited. Can we do something in an edition change to remove the unnecessary type bounds somehow? Or just accept an unused type bound? Probably wouldn't work with impl SliceIndex<[i32], Output = [i32]> though.

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