On 13-02-20 04:41 PM, Brian Anderson wrote: > Because sometimes `mod driver;` means look in the current directory, and > sometimes it means look in a subdirectory, doing this would require > that, when the parser sees `pub mod driver;`: > > 1) look in the current directory for `driver.rs` > 2) if that fails, look in the `driver` directory for `mod.rs` > > That's not necessarily bad, but it's a small bit of non-obvious > behavior. I haven't been thrilled with the `mod.rs` convention (because > my emacs buffers all have the same name) so I haven't been using it on > new code, but I think if we go with the `lib.rs`/`bin.rs`/`pkg.rs` > naming for crates in packages, then we should also settle on `mod.rs` > for directory modules, in which case I think I'm fine with this change.
Yeah. I was also thinking we should do this, and was considering the 2-step rule you describe above. I think it models the evolution of a library _reasonably_ well: you start by making foo.rs and then later it grows and you realize it's got submodules so change to foo/mod.rs and foo/otherstuff.rs etc. The rule above means most clients don't need to change as you refactor. It's convenient for developers and not entirely surprising for readers. (You'll probably want to double check that 1 and 2 are mutually exclusive though; that is, not-accept foo.rs when foo/mod.rs exists) -Graydon _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
