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.
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.
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.
The rewrite in question would just add pub use ident::*; for each mod ident;. Why does that need to know about what is inside?
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.
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.
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.
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.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.