Feature Request: add a trait the same as std::ops::Index but returns an object rather than a reference

[Fancyflame]

Description: Add a trait the same as std::ops::Index except the return of fn index is Self::Output rather than &Self::Output.

Motivation: Please consider this code

pub trait MyIndex<Idx>{
    type Output: ?Sized;
    fn index(&self,index:Idx)->Self::Output; //Notice the return value here
}

struct Foo<'a>(std::collections::HashMap<u32,&'a str>);

impl MyIndex<u32> for Foo<'_>{

    type Output=String;
    fn index(&self,index:u32)->Self::Output{
        let mut s=self.0[&index].to_owned();
        s.make_ascii_uppercase();
        s
    }

}

To make the example simple I just used make_ascii_uppercase as mutable operation, but in real practice, it probably contains much more complicated steps to get the value and process it, that's why I raised this topic.

[CAD97]

Generally, the indexing syntax is useful for code clarity in that it returns a view (reference) into the indexed object.

What benefit (other than terseness) do you get by returning an owned 'static value from indexing? That isn't provided by just a .get()?

Additionally, what happens if you implement both Index and MyIndex? If you can't, how is that enforced?

Previously:

Should (array) view be an internal type?

The motivation for this post is to get some feedback on a potential solution to a problem discussed several times before. I have not seen this exact solution being discussed, but perhaps it is trivially bad without me realizing it. What I want answered is if it is worth pursuing the problem further or if by some detail of how the language or the compiler works it is inherently a bad idea. The problem is concerned referencing a view in some larger array. I have attempted to structured the text t…

Should (array) view be an internal type?

The biggest flaw with proposals to make indexing return a custom view type, as I understand it, is actually quite simple and fundamental: thing[index] isn't actually sugar for calling Index::index! It's actually quite complicated and very directly coupled to references and autoref rules, in that roughly: thing[index] is typed as a place (rvalue) of type Index::Output. If the place is used by mutable reference, either via autoref rules or directly taking &mut of the place, IndexMut::index_mu…

Pre-RFC: Returning Proxies from Index/IndexMut

There's a thread (now closed) about generalizing Index and IndexMut to return "view" types that aren't references. There's also a prior RFC which was declined for accidentally proposing a solution that breaks backwards compatibility. Here, I'd like to discuss a potential non-breaking solution: adding new indexing trait which supersedes the old ones, while providing covering implementations for types that implement the old types. More concretely: trait CoolIndex<'a, Idx: ?Sized> { type Outp…

Pre-RFC: Returning Proxies from Index/IndexMut

&var[idx] isn't translated to &(Index::index(&var, idx)). It's translated to Index::index(&var, idx). The introduced reference is "lost", and effectively it is your var.index_by_ref(idx), as var.index(idx)/Index::index(&var, idx). The point I'm trying to convey is that &var[idx] evaluating to a type that isn't &_ is going to be surprising, and lose the affordance that the current syntax has. On top of this, if [] doesn't always return T, &T, or &mut T, but instead, for example, returns Result<T…

(Wow I've argued this point a fair number of times... indexing returning a custom type seems like an obvious extension, it just runs into a whole thorny bush of issues once you start digging into the implications. Maybe I should write up some lang design notes to this effect...)

[programmerjake]

how about:

pub trait Index2<I> {
    type Output;
    fn index(self, index: I) -> Self::Output;
}

impl<'a, T: Index<I>> Index2<I> for &'a T {
    type Output = &'a <T as Index<I>>::Output;
    fn index(self, index: I) -> Self::Output {
        Index::index(self, index)
    }
}

// similar impl for IndexMut

[CAD97]

The question then though is how do you choose between Index2 for &T and Index2 for &mut T when you're indexing T? It's decided via autoref rules today, and won't work without autoref extensions for Index2.

Honestly, I'd read both my linked threads (they're relatively short) and unless you (the proposer in general) have answers to my concerns raised in the threads, I doubt any new index trait will work (without more mountains of special behavior), let alone be worth the churn of changing how indexing is done.

[carbotaniuman]

I tried proposing the change here, but ultimately shelved it because of a lack of time and realizing custom DSTs are the way for a lot of this.

There was a post somewhere explaining how a lack of reborrowing makes returning structs pretending to be refernecs would be very painful, and also there would probably be a lot of churn. As written, they wouldn't allow returning references to data, ruling out stuff like NumPy views, leaving the main use case being BitSets and IndexMut for HashMap.

The existing behavior of code related to the Index traits is non-trivial, but it's also not overly complicated either. I would surmise the hardest part would be demonstrating that these traits would be worth the increased complexity in the indexing process.