RFC:fused 'use mod' imports with relative paths

[dobkeratops]

No description provided.

[chris-morgan]

I don’t understand this clearly at all, especially the motivation. It seems to me it makes the rules considerably more complex for no concrete benefits that I can see.

Where the modules actually exist and where they are loaded is not clear to me. Can you elucidate on how this fits in with use and mod and so on?

[dobkeratops]

let me see if i can explain better :(

Its' analogous to doing a unity build in C++ for a header-only project, with #pragma once,with a graph of includes from each header describing dependancies, 'use mod' being like #include "some/relative/path.h" and of course adding corresponding extra namespace information.

especially the motivation.

The idea is to exploit the coherence between the module heirarchy and the filesystem directory heirarchy - but imagine if you assumed that coherence, instead of relying on 'mod.rs' file to create it.

If relative file paths and module paths are used, imagine if every individual file specifies its dependancies: you should be able to spider out from the root to load everything.

So the idea is that "use mod" statements simultaneously load (if not already loaded) and bring into scope locally.

It seems to me it makes the rules considerably more complex

Its more complex alongside the existing system (think of a rolling refactor), but on its own it might be simpler? - you just see relative paths, never absolute - and you could work purely with use mod (no separate uses needed) if you wanted.

"Where the modules actually exist"

• They'd exist relative to wherever you started compiling. With the modules & filesystem coherent, it's unambiguous.( Perhaps i've explained confusingly by starting out showing how super:: would be like ../ for files deeper in a heirarchy referring back to earlier ones.)

"and where they are loaded is not clear to me."

every file specifies the other files it depends on; So there is not one place its' loaded, rather the implementation would have to say "if this requested file hasn't been loaded yet, load it now."

If there were no submodules within files, then just the information in 'use...' statements (if made relative) would do it.
However my proposal doesn't eliminate those - it assumes every file-level module will be referenced at least once in a 'use mod' statement.

Can you elucidate on how this fits in with use and mod and so on?

it could replace 'mod'.
It would still be useful to have 'use' statements in conjunction with this, to bring individual symbols in. Otherwise, you'd always have to prefix a qualifier when using any symbol out of scope.

More detail would be possible,e.g.
use mod baz::foo{list,of,symbols,goes,here..} /* loads baz/foo.rs, and brings those symbols into scope_/
use mod b= bar /_ load bar.rs and give it's module the alias 'b' locally*/

especially the motivation.

there would be no difference in how files are loaded or symbol-paths are specified between a project being divided into many crates, or compiling the entire source code as one crate.
In C++ you have the option of doing a unity build (one giant crate) or 'each file is a translation unit' .. you would get that flexibility here. At present, to change from one scenario to the other, you have to manually setup crates loading modules and inter-file paths , all differently.

[alexcrichton]

That you for taking the time to write out this RFC! We discussed this at the triage meeting today and decided to decline this. Currently use isn't very special in terms of what this is proposing, and we'd like to maintain the current method of defining modules. As a result, I'm closing this.