Several people have mentioned that they are not happy with the camelcase convention for module names. (I am actually among those people.) A suggestion was made to go back to lowercase module names, and to use different syntax for module dereferencing and record/object/tuple dereferencing. If we follow Perl/C++ you'd get std::vec::len(x). That way, module names an other names can be, mostly, statically distinguished, and modules can live in a different namespace from other names.
(I say mostly, because 'import foo::bar' is still ambiguous—is 'bar' a module or a name? We could require 'import foo::bar::' in the former case, or something like that.) Working on the resolver has made me more sympathetic to this proposal. I rather like the simplicity of std.vec.len, but it requires the resolver to mangle the AST, since only at that stage is it clear what's an expr_field. It'd be nice if the parser could handle this without full knowledge about all used crates (also important for external tools implementing 'jump to definition' and such). So, I could 1) Implement this 2) Using our advanced transitional snapshot technology, follow up said implementation with another monster commit that renames std modules back to lowercase, and replaces all the right dots with the new module dereferencing operator. (I think this can be done with some creative regexping, since our set of module names is still rather small, so I won't have to put the pretty printer into play yet) One more thing I'd like to put out there: If we do something scary and make a colon followed by an alphabetic character a different token than one followed by something else, we can make the module dereference operator a single ':'. I think our users will thank us, on the whole, for the extra succinctness, but there is the issue of it being slightly obscure -- you'll never even notice this rule when writing well-formatted code, but then when, in a fit of naughtiness, you omit the space in front of your typestate constraint, you'll get an error. I think this is not a big problem, since your mistake will be easy enough to figure out, but it's something to consider. Let me know what you think. Best, Marijn _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
