Writing a non-trait impl for a struct in a different module makes it impossible to construct that struct directly

[huonw]

Commenting out the impl makes the build succeed.

mod foo {
    use super::*;

    fn bar() -> Foo {
        Foo { x: 1 }
    }
    impl Foo { }
}

pub struct Foo { x: int }

fn main() {}

mod-error.rs:5:8: 5:11 error: `Foo` does not name a structure
mod-error.rs:5         Foo { x: 1 }
                       ^~~
error: aborting due to previous error

[SiegeLord]

A workabout for this is to qualify Foo. E.g. this works:

mod foo {
    fn bar() -> super::Foo {
        super::Foo { x: 1 }
    }
    impl super::Foo { }
}

pub struct Foo { x: int }

fn main() {}

Note that it still won't work perfectly, as you are liable to hit #9584 in the process.

[chris-morgan]

Just ran across this when implementing an extra method only in tests.

You actually don’t need to always qualify foo; just on the impl. (This will trigger the unnecessary_qualifications lint, but it’s set to allow by default—I just happen to have decided to be very strict in the Teepee codebase.)

[bstrie]

@chris-morgan assures me that this is a manifestation of the same bug, although it expresses itself as the sudden invisibility of an inherent impl from a different module:

use Foo::Bar;

mod Foo {
    pub struct Bar {
        pub x: int,
        y: int
    }

    impl Bar {
        pub fn new(new_x: int, new_y: int) -> Bar {
            Bar { x: new_x, y: new_y }
        }
    }
}

impl Bar {
    fn set_x(&self, new_x: int) {
        self.x = new_x;
    }
}

fn main() {
    let bar = Bar::new(1, 2);  // error: unresolved name `Bar::new`.
    println!("{}", bar.x);
}

So this is no longer an issue given that inherent impls are now only allowed in the same module?

[steveklabnik]

@jakub- yup