Thanks, you are right.
So correcting myself:
1) It doesn't require super, ::b works as well. It makes sense.
2) It works if *use* is in right scope, in this case inside a_inner. I must
admit it's a bit surprising that imports are not inherited from the parent
scope.
4) #[feature(globs)] works fine, when I have *use* in proper scope
Thanks for example with trait T for type A, it makes sense.
I guess I just need some small project in rust to get better feel of the
language.
let this be a lesson in humility for me ;)
2013/12/13 SiegeLord <slab...@aim.com>
> On 12/13/2013 02:57 PM, Piotr Kukiełka wrote:
>
>> I understand that one could want flexibility and matching file with
>> package is not always optimal.
>> And it's not what I wanted to suggest in first place ;)
>>
>> Let's clear one confusion first. When I said that I think *mod* and
>> *extern mod* are redundant I thought about using them in context of
>> importing.
>>
>
> I do not think it is correct to think of `mod foo;` as importing anything.
> Rust's module system is not based upon files: files are just a convenience.
> "mod foo;" is literally just a shortcut for `mod foo { <paste the contents
> of foo.rs or foo/mod.rs> here> }`. You could write every crate in Rust as
> a single file per crate without changing the semantics at all.
>
>
> > Now, I don't see big difference between mod and extern mod, because in
> both cases intention is very similar: you want to signalize that required
> modules are in external crate.
>
> `mod foo;` does not signify that modules are in an external crate, it
> signifies that they are in the same crate. There are some big differences
> to whether a module is in a separate crate or not. For example, if crate
> Crate1 has a trait T and a type A, Crate2 cannot implement trait T for type
> A. If T and A were in a different module of Crate2, then it would be able
> to implement T for A. This is a very important property of the crate
> system, and making it confusing by merging `mod` and `extern mod` is a bad
> idea, in my opinion.
>
>
> > This means to make it work correctly I need to add extern mod clib; in
> both files (then it compiles and works).
>
> No, that's not the case. To make it work you can do:
>
> ~~~
>
> //------------------------- a.rs ---------------------------
> mod b;
>
> pub mod a_inner {
> pub fn a_func() { ::b::clib::c_func2(); }
> }
>
> fn main() {
> a_inner::a_func();
> }
> ~~~
>
> A similar modification will work with moving `extern mod clib` into a.rs.
>
> The 'notices' you've written suggest to me that you don't completely
> understand how the module system works today, which is very important to do
> before suggesting changes to it (even if it's flawed you still need to
> understand it). I suggest reading the relevant portion of the tutorial
> again. All 4 'notices' you mentioned maybe become more clear then.
>
> -SL
>
> _______________________________________________
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
