Private trait's methods reachable through a public subtrait

[bluss]

I'm not 100% sure how the privacy rules should work.

A's methods should not be callable because the trait is private, but it's reachable though the trait C that inherits A, by calling C::a().

B's methods are reachable the same way, even if it's marked pub but not publically reachable.

pub use inner::C;

mod inner {
    trait A {
        fn a(&self) { }
    }

    pub trait B {
        fn b(&self) { }
    }

    pub trait C: A + B {
        fn c(&self) { }
    }

    impl A for i32 {}
    impl B for i32 {}
    impl C for i32 {}
}

fn main() {
    // A is private
    // B is pub, not reexported
    // C : A + B is pub, reexported

    // 0.a(); // can't call
    // 0.b(); // can't call
    0.c(); // ok

    C::a(&0); // can call
    C::b(&0); // can call
    C::c(&0); // ok
}

Playpen

[bluss]

cc @alexcrichton, because you've weighed in on other privacy issues

[alexcrichton]

I would personally expect a privacy error to be generated. I'm also a little surprised about how resolution allows using a method without importing the trait as well, but that may perhaps be intended behavior.

cc @rust-lang/lang, @nrc

triage: I-nominated

[bluss]

C::b being callable seems to suggest b is a method in the C trait, "inherited", but .b() not being callable as a method when C is in scope is a counterargument.

[nikomatsakis]

I think the error here is that pub trait C: A + B ought to require that A is public.

[nrc]

public or accessible from all the places C is? If it is in another module, it could be public but we could still have this problem (with a more complex example). The alternative feels hard to check though.

[alexcrichton]

I'd be fine so long as it was limited to "marked pub" because that's generally how the public/private check works in terms of what you can export.

[nikomatsakis]

I am somewhat surprised, but this test case passes too. The difference here is that the type I32 is private, so I expect the impl to be in error.

mod inner {
    struct I32;

    trait A {
        fn a(&self) { }
    }

    pub trait B {
        fn b(&self) { }
    }

    pub trait C: A + B {
        fn c(&self) { }
    }

    impl A for I32 {}
    impl B for I32 {}
    impl C for I32 {} // <-- I expected an error here and on the impl of B
}

fn main() {
}

[pnkfelix]

(I'm inclined to think that the invocation C::a(&0) from the original example is still problematic, independently of the example @nikomatsakis gave above.)

[pnkfelix]

(namely, if one changes @nikomatsakis example so that it says pub struct I32;, then we would still have the issue of whether 1. one can have the declaration of pub trait C: A { ... } and 2. whether one can call the methods from the private trait A on a type where only the public trait C is available for use.)

[nikomatsakis]

The heart of this question is what a private trait means. After some discussion in the language team, we came to the following conclusions:

• To be consistent with the rest of the rules, private types and traits should not appear in the where-clauses (or supertraits) of public traits. This would make pub trait B: A an error. I believe this is the in the spirit of the relevant RFC, I've not reviewed the precise wording.
• Furthermore, if we ever were to relax this rule, we would want to define when you can call a method on a private trait. It might make sense to make that illegal outside of the module that defined the trait.

There is definitely concern that people are going to be relying on this kind of setup, though also concern that they may not be getting the guarantees that they think they are.

[nikomatsakis]

triage: P-high