Hi all,
I'm new to rust but I'm quite interested in learning it more deeply and
contributing to language itself.
However right now I'm just studying tutorial/manual/wiki to understand it
better, and sometimes I have doubts about language design.
My biggest concern so far was connected with module system.
Right now rust have 3 different (if I'm counting correctly) keywords used
for marking which library/module should be imported and used.
Why not just one? It would actually solve few problems at once.
So, this is my idea:
Drop *mod* and *extern mod *keywords and just leave *use*.
Since there would be only one keyword responsible for importing left, you
wouldn't need to care about their order.
Then, when compiler see new identifiers it checks:
1) If there is local definition of it available? If there is, then we are
done.
2) Is there matching import in scope?
a) If yes, then is it labeled with resource path marker?
*) If yes, then check if it's:
+) Path to local file => it's equivalent of #[path=".."]
mod rust;
+) Something like "http://github.com/mozilla/rust"; =>
it's equivalent of extern mod rust = "github.com/mozilla/rust";
+) Something like "rust:0.8" => it's equivalent of extern
mod my_rust(name = "rust", vers = "0.8"); *) If no, then first
check local mods, and if nothing is found then scan libs (extern mod)
b) If no, then it's unknown symbol and we got error
What are the real benefits?
1) End user just need to remember and understand one syntax, *use, *
examples:
use farm;
use my_farm(path = "farm", vers = "2.5");
use my_farm(path = "http://github.com/farming/farm";, vers = "2.5");
use my_farm(path = "../../farm/farm.rs");
2) You don't need 3 special keywords
3) Order of use doesn't matter (and there are no doubts about shadowing
order).
4) You don't need special cases use super and use self, you can use path to
replace them as well (i.e. to replace self: use some_child_module::
some_item(path = ".");)
5) You won't link unused modules even if they are imported with *use.*
6) If I'll decide to move part of my modules to separate library it can
still work without code changes
7) It would be easy to implement imports which works only in scope this way
(as it is done in scala for example)
8) this way use works more like import on jvm than include in C/C++ (and I
think C style include should be avoided)
Downsides?
I probably don't know all corner cases and maybe there are good and valid
reasons to do it as it done right now.
But unless they are really good then I think simplification of imports
should be seriously considered.
Best regards,
Piotr Kukielka
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
