pre-RFC: inline mod

[le-jzr]

I like this.

Bikeshedding time: Instead of inline mod, how about we just collapse the existing keywords?

 pub use mod and_then;

I’m suggesting it because this is a thing I actually tried, and was disappointed it didn’t work.

[petrochenkov]

Facade pattern as described in the futures example is equivalent to

mod my_mod;
pub use my_mod::*;

, so inline mod can desugar exactly into this construction.

It would also solve the question about items private to an inline module naturally - they will stay private an won’t be accessible from the parent unless marked with pub(super).

Reference-level explanation

$vis inline mod my_mod;

is desugared exactly into

$vis mod my_mod;
pub use my_mod::*;

Reference-level explanation (variation 1)

inline mod my_mod;

is desugared exactly into

mod my_mod;
pub use my_mod::*;

Visibilities on inline modules are prohibited as confusing.

Note

Due to filtering properties of glob imports pub use my_mod::* keeps visibilities of items defined in my_mod intact when reexporting, i.e. pub items will be reexported as pub, pub(crate) items will be reexported as pub(crate) etc.

[RalfJung]

One open question is whether items private to the submodule should be accessible from the parent. I suspect it would be better to have them remain private and only place items which are accessible outside the submodule into the parent, but I don’t have a huge preference for this.

I think having them private is needed to make this useful. In fact, the futures motivation you borrowed explitily states that it wants helper functions private to that file.

[ahmedcharles]

Doesn’t this specification result in my_mod being introduced as an item? One of the things I liked about the initial specification is that module ends up being completely transparent, which prevents code from accidentally referring to the reexported items via multiple paths. Does that seem like a desired property?

[petrochenkov]

Does that seem like a desired property?

Probably not.

If you want a “public facade” (like std::collections), you can write pub inline mod my_mod; and it will need to create a proper item named my_mod.
If the facade is an implementation detail, you can write inline mod my_mod; and just not to refer to my_mod in the current module, others won’t be able to refer to it anyway because it’s private.

This also may be useful for disambiguation.

inline mod collection1;
inline mod collection2;

let it: Iter: // ambiguity on use
let it: collection1::Iter; // OK
let it: collection2::Iter; // OK

[RalfJung]

I really like the idea of files being anonymous modules which still have privacy from each other, and only folders being “actual” modules. I think that should be possible, or even the default, in whatever we end up with.

That said, with data showing that the difference between “use” and “mod” is very confusing for newcomers, I am not sure if still having “mod” at all is a good way forward. Indeed this concept is fairly unique to Rust it seems (not entirely unique though, e.g. the Coq proof assistant has a very similar scheme).

Incidentally, not having mod and having files be anonymous could even mean that mod.rs is in no way special any more, again making teaching simpler.

[petrochenkov]

with data showing that the difference between “use” and “mod” is very confusing for newcomers

Where can I look at this data?

[petrochenkov]

with data showing that the difference between “use” and “mod” is very confusing for newcomers

I personally find this hardly believable, partially because I still remember how I learned the language.

"Module ≈ namespace in C++, mod m; is a namespace put into a separate file to avoid huge files."
That’s all, that was one of the simplest things in the language, and nothing seemed related to use at all.

What I found non-trivial is where exactly mod m; finds the file with code for namespace m, especially the m/mod.rs case, I had to carefully repeat the examples from rust-by-example before it clicked.

One more thing that I found surprising (but simple) is that names from outer modules are not in scope in inner modules. This is different from C++, but it’s one of the cornerstones of Rust module system.

Still all these details were completely dwarfed (by orders of magnitude) by efforts spent on learning libraries, so I honestly don’t understand many attempts to make things that are already simple “less confusing to newcomers”, it’s a drop in the ocean.

[skade]

I don’t like this proposal.

I find the futures example flawed, as futures-rs does indeed not re-export all items from these modules into the parent module, only the main struct, but for example not the construction function new, which is exported as and_then::new.

The described example would fail to compile, because most of these modules define a function called new.

The whole setup of RFC sounds a lot of c-style textual replacement, which brings it’s own share of issues: it’s all or nothing and is prone to collisions, which a lot of similarly structured modules bring with them. Also, such the system is prone to accidentally introducing names into the namespace.

Reusing terminology like inline makes it hard to separate function inlining from the proposals usage of the word and will confuse beginners.

The usage of the facade pattern in the futures-rs points to where the described way to work is indeed good: Every module implements a richer interface than the exported one, which is subsequently made thinner through the re-exports.

[skade]

“Module ≈ namespace in C++, mod m; is a namespace put into a separate file to avoid huge files.”

I agree with the rest of your post, but a considerable amount of newcomers to Rust are not from a C++ background.

[RalfJung]

Where can I look at this data?

@aturon has collected a bunch of data

[ahmedcharles]

It’s my understanding that items which want to be reexported for use outside the crate would be tagged with pub and ones for use in the crate would be pub(crate) or pub(super), which means that the example isn’t flawed, it just needs to take advantage of some other features which were recently added.

@petrochenkov provided feedback about how to specify this to avoid defining it as a textual replacement (I never wanted it to be actual textual replacement, for what it’s worth. The point of the pre-RFC is to improve on the idea through feedback). I’ll be updated the text to reflect those changes.

Using the word inline is purely a bikeshed discussion. I’m not tied to the word used in any way, but unless you have a concrete suggesting, just saying that inline is confusing isn’t as helpful.

And the only goal of this RFC is to make the facade pattern more usable.

[NeoLegends]

Forgive me for my naivity, but why can’t we just solve this with a plain old macro that does the desugaring? Something like

inline! {
    mod foo;
    mod bar;
}

that would desugar like the proposed way.

[mindsbackyard]

Because the macro cannot know what’s inside of foo and bar. macro_rules! macros can only reorder/rewrite tokens. You need at least proc_macros for this (see the former post), but even that does not work atm.

[le-jzr]

The rewrite in question would just add pub use ident::*; for each mod ident;. Why does that need to know about what is inside?

[mindsbackyard]

Actually … true. I always had the picture in my mind that inline would work transitively and flatten the submodules’ hierarchy. But that’s not what has been proposed.

[ahmedcharles]

I’d probably prefer #[facade] and that’s already documented as an alternative in the RFC, but then again, I don’t understand macros well enough to know how to implement that currently.

[mindsbackyard]

I tried to implement an experimental prototype which can be found in the facade_attr repo. It would be nice to know if it works as intended by the pre-RFC. I implemented an optional pseudo hiding of the annotated module based on name mangling.

I also discovered something interesting which I did not know before: Before the macro handler is invoked the submodule which is referenced by mod submodule is fully inlined by the compiler, i.e., it is transformed to mod submodule { ... content of submodule.rs ... }. So the macro handle can access all of the contents of the submodule.

[vi0]

Won’t this invite more usage of (or be equivalent to) use ...::*, which hurdles finding where a symbol goes from when not using IDE?

I expect * to be avoided in production code just like from ... import * avoided in Python.

[system]

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