Module paths suggestion

1

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/foo.rs    fn something()
qux/bar.rs

if you write foo::something() in ‘bar.rs’, 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)”

2

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.

3

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

4

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
5

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.

6

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.

7

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.