Private type in exported type signature when it shouldn't

[tomaka]

This code:

mod A {
    struct X;

    mod B {
        use A::X;
        pub fn foo(_: X) {}
    }
}

Triggers:

src\main.rs:6:23: 6:24 error: private type in exported type signature
src\main.rs:6         pub fn foo(_: X) {}

The foo function is only visible to A and B, and X is also visible to both A and B, so I don't see why this would be forbidden.

This was introduced in the rustc 1.0.0-nightly (f4e0ce66a 2015-03-19) (built 2015-03-20) nightly. With the 2015-03-17, this works.

[tomaka]

Probably related to #23290 #22261

cc @nrc @nikomatsakis then

[alexcrichton]

I believe that this is intentional behavior, this is a safeguard against reexporting foo at a reachable location for the crate, for example:

pub use A::foo;

mod A {
    pub use A::B::foo;
    struct X;

    mod B {
        pub fn foo(_: super::X) {}
    }
}

[tomaka]

Shouldn't the reexport trigger an error then?

This removes a lot of flexibility in the modules system.
Instead of splitting functionnalities in multiple submodules, this will force users to put everything in the same file, leading to big blobby files with thousands of lines of code.

[nrc]

This is indeed intended behaviour (although not optimal). Basically, we have a very simple rule which is safe - public signatures can never include public types. There is a more optimal rule which we might implement in the future which takes in to account the privateness of the modules (see discussion on the bugs).

The re-export is not an error because it is not public - it is perfectly fine to use X inside B in private fns, etc.

[tomaka]

That is disappointing, I was convinced that it was a bug.
In glutin I now have to use a few dirty hacks to bypass this restriction, and I have no alternative except code duplication.

[tomaka]

Also, this compiles when it shouldn't:

mod B {
    pub use self::A::foo;

    mod A {
        pub struct X;
        pub fn foo(_: X) {}
    }
}

foo is now accessible from the outside but not X.

This new rule is too restrictive and doesn't even totally protect you.

[nrc]

I filed #23621 for the bug above