A strange processing methods visibility

rustc 1.0.0-nightly (2b01a37 2015-02-21) (built 2015-02-22)

I create file with content:

use std::hash::SipHasher;
use std::hash::Hasher;

fn main() {
}

fn compile_fail() {
    let hasher = SipHasher::new();
    hasher.write(&[0, 1, 2]);
}

fn compile_work() {
    let sip_hasher = SipHasher::new();
    let hasher: &mut Hasher = &mut sip_hasher;
    hasher.write(&[0, 1, 2]);
}

And have compilation errors:

private.rs:9:2: 9:26 error: method `write` is private
private.rs:9    hasher.write(&[0, 1, 2]);
                ^~~~~~~~~~~~~~~~~~~~~~~~
error: aborting due to previous error

I do not understand what is happening due to this error, because this cast is essentially doing nothing.

SipHasher has both a private write method and a public one implemented in Hasher trait for it. The former shadows the later. Probably related to #12808.

This is rather confusing from user's point of view. Because by definition, a private method doesn't show up in the rustdoc. So looking up rustdoc doesn't help diagnosing this particular error.

I wonder what is the optimal solution here. Maybe an help message of some sort?

I've created a self-contianed example of this behavior:

mod foo {
    pub struct Foo;

    impl Foo {
        fn bar(&self) {
            println!("private bar in foo");
        }
    }

    pub trait Baz {
        fn bar(&self);
    }

    impl Baz for Foo {
        fn bar(&self) {
            println!("public bar in foo from Baz");
        }
    }
}

fn main() {
    let mut f = foo::Foo;
    f.bar(); // doesn't work

    let b: &mut foo::Baz = &mut f;

    b.bar(); // works
}

/cc @rust-lang/lang . I am not sure that this is fixible? It would seem like a big change to modify these rules.

Nominating for discussion at next lang team meeting.

@edwardw

As @edwardw said, this is (to my mind) the same "FIXME" as #12808 (which just talks about fields). I think we can probably change this, because we'd just be making more code compile, but I've not thought super hard about that.

In @rust-lang/lang meeting we decided that this should indeed follow the same lookup rules as #12808.

triage: P-medium

@nikomatsakis

@nikomatsakis This is fixed in the above PR -- I'll add @steveklabnik's example as a test.

Auto merge of #31938 - jseyfried:autoderef_privacy, r=nikomatsakis

Merge pull request rust-lang#22684 from ChayimFriedman2/little-docs

Navigation Menu

A strange processing methods visibility #22684

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

A strange processing methods visibility #22684

Description

Activity

edwardw commented on Feb 24, 2015

edwardw commented on Feb 24, 2015

steveklabnik commented on Mar 4, 2016

aturon commented on Mar 7, 2016

nikomatsakis commented on Mar 7, 2016

nikomatsakis commented on Mar 10, 2016

nikomatsakis commented on Mar 10, 2016

jseyfried commented on Mar 11, 2016

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions