Description
These are all legal, and somewhat strange, since they're not really following the file-system analogy that modules are typically explained with. I expect this behaviour is just whatever happens to fall out of the current implementation strategy, so let's make a more explicit decision one way or another.
static X: u8 = { mod foo; 0 };
fn foo() {
mod foo;
}
fn main() {
mod foo;
}
As one might expect, each of these is a distinct instance of foo
(which can be verified by placing log_syntax(hello)
in foo.rs
: the compiler will greet you 3 times).
Noticed in https://users.rust-lang.org/t/are-module-declarations-allowed-inside-functions/3583 .
Activity
nikomatsakis commentedon Nov 12, 2015
This seems weird to me. I think the intention is that the out-of-line syntax (
mod foo;
) should only work at the top-level.aturon commentedon Nov 12, 2015
I'd vote for allowing non-inline modules only at the top-level, to retain a clear mapping to the file system.
nikomatsakis commentedon Nov 12, 2015
(Or nested inside modules.)
nikomatsakis commentedon Nov 12, 2015
triage: P-medium
Backwards incompatible, but ... kind of a curiousity.
matklad commentedon Nov 14, 2015
Found one more mod aliasing scenario. It involves several files, and is semi officially allowed by the reference.
The layout
The files
The copy module will be aliased. The problem is that although
foo
andbar
are not directory owners, their inner modules are.(RES): implement child modules resolve
(RES): implement child modules resolve
(RES): implement child modules resolve
2 remaining items
matklad commentedon Nov 16, 2015
It is forbidden because
foo
is not a directory owner.matklad commentedon Nov 16, 2015
Just in case here is a repository with the example: https://github.com/matklad/nested-mod
I don't see a reason to allow user to shoot himself in the leg. What if you accidentelly have identical
path
attributes (copy paste problem)?My main concern though is that non injective file to module mapping may complicate the implementation of some rust tools. Here is another hypothetical example of this. Suppose you implement incremental compilation for rustc. You will need a mapping from files to modules. If mod aliasing is alowed, then you will need a multimapping. So you end up with more complex code which is used only in a tiny fraction of projects and because of this probably contains some bugs.
nikomatsakis commentedon Dec 1, 2015
@matklad
Ah, I see. So it seems to me that the problem is that
mod inner { mod copy; }
should not be allowed in contexts wheremod copy;
would be illegal. In other words, an inline module should only be considered a "directory owner" if it is located within a directory owner.A compromise might be Yet Another Lint Warning. ;) I agree with you about preventing people from shooting themselves in the leg, but I guess I think people don't use
#[path]
lightly or frequently, so this seems unlikely to be a major source of confusion.matklad commentedon Dec 1, 2015
I totally agree that this curiosity is insignificant for users. But I still worry more about the implementation side of the issue, and a lint warning does not help here.