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

Index syntax autoderef is different from direct method call #15757

Closed
tomassedovic opened this issue Jul 17, 2014 · 3 comments · Fixed by #18486
Closed

Index syntax autoderef is different from direct method call #15757

tomassedovic opened this issue Jul 17, 2014 · 3 comments · Fixed by #18486
Labels
E-mentor Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion.

Comments

@tomassedovic
Copy link
Contributor

The col[i] syntax seems to do some autodereferencing of col, but it doesn't work with && and Rc. This is confusing because method calls dereference as much as necessary:

use std::rc::Rc;

fn main() {
    let v = vec![1u, 2, 3];
    println!("first item: {}", v[0]);  // OK

    let v_ref = &v;
    println!("first item: {}", v_ref[0]);  // OK

    let v_ref_ref = &&v;
    println!("first item: {}", v_ref_ref.index(&0));  // OK
    // Fails, should be equivalent to the above:
    println!("first item: {}", v_ref_ref[0]);
    // error: cannot index a value of type `&&collections::vec::Vec<uint>`
    // println!("first item: {}", v_ref_ref[0]);
    //                            ^~~~~~~~~~~~

    let v_rc = Rc::new(vec![1u, 2, 3]);
    println!("first item: {}", v_rc.index(&0));  // OK
    // Fails, should be equivalent to the above:
    println!("first item: {}", v_rc[0]);
    // error: cannot index a value of type `alloc::rc::Rc<collections::vec::Vec<uint>>`
    // println!("first item: {}", v_rc[0]);
    //                            ^~~~~~~
}

I'm not sure if this is related to issue #15734. The circumstances seem different, but the underlying cause might be the same.

$ rustc --version
rustc 0.12.0-pre-nightly (459ffc2adc74f5e8b64a76f5670edb419b9f65da 2014-07-17 01:16:19 +0000)
@pnkfelix
Copy link
Member

cc me

@eddyb
Copy link
Member

eddyb commented Sep 27, 2014

The indexing methods take self by reference, so no autoderef is necessary in that case, i.e. it seems that the autoderef behavior was mistakenly removed and @pcwalton agreed when I asked him.
I am willing to mentor someone on this, as it should be straight-forward and it has been a minor annoyance for more than two months.

@jdm jdm added the E-mentor Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion. label Sep 27, 2014
@nikomatsakis
Copy link
Contributor

Would be fixed by #18486

bors added a commit that referenced this issue Nov 5, 2014
This branch cleans up overloaded operator resolution so that it is strictly based on the traits in `ops`, rather than going through the normal method lookup mechanism. It also adds full support for autoderef to overloaded index (whereas before autoderef only worked for non-overloaded index) as well as for the slicing operators.

This is a [breaking-change]: in the past, we were accepting combinations of operands that were not intended to be accepted. For example, it was possible to compare a fixed-length array and a slice, or apply the `!` operator to a `&int`. See the first two commits in this pull-request for examples.

One downside of this change is that comparing fixed-length arrays doesn't always work as smoothly as it did before. Before this, comparisons sometimes worked due to various coercions to slices. I've added impls for `Eq`, `Ord`, etc for fixed-lengths arrays up to and including length 32, but if the array is longer than that you'll need to either newtype the array or convert to slices. Note that this plays better with deriving in any case than the previous scheme.

Fixes #4920.
Fixes #16821.
Fixes #15757.

cc @alexcrichton 
cc @aturon
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
E-mentor Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants
@jdm @eddyb @tomassedovic @nikomatsakis @pnkfelix and others