Module paths suggestion


r.e. rust’s use of both Absolute and Relative paths. (use is absolute, whilst in code its relative?)

I gather there was a suggestion to make code ‘try relative, then if not found try absolute’

Imagine if this was generalised, e.g. given

qux/    fn something()

if you write foo::something() in ‘’, it would look for these, in order:- [1] ::qux::bar::foo::something() i.e self::<path> [2] ::qux::foo::something() i.e. super::<path> [3] ::foo::something() i.e super::super::<path> etc

i.e. … “let x=current path; do { if x::(given path) exists, return it, else pop last element from x and try again} while (x)”


Can I suggest an opposite change? : )

Prohibit absolute paths in code, they are rarely (?) used anyway. Then use declarations will become the only “points of import” for a module and will create an easily extractable dependency graph for modules, which will facilitate partial recompilation.


You can’t always ensure that the relevant use statement exists, eg whilst writing macros.


I like the idea of removing the :: whenever it is possible, but :

  • I’d prefer to rise an error, if there is conflict between absolute and relative path.
  • the second case seem weird to me. IMO there should only be absolute and “relative to current module” path


Could your give an example? Can’t the use statements be incorporated into macros themselves?

I have no well thought opinion on this issue, but I have a concern, that with absolute paths modules will sometimes step on the same rake as headers.


This can’t be done for macros which expand into patterns, e.g.

macro_rules! none {
    () => { ::std::option::None }

fn foo(x: Option<u32>) {
    match x {
        none!() => println!("foo"),
        _ => {}

It would also break macros that expand into items which need to reference some external path.