# Unbaked Idea: DRY using "parameterized inline modules" **URL:** \ **Category:** Uncategorized\ **Created:** [June 26, 2018, 5:30am UTC](https://internals.rust-lang.org/t/unbaked-idea-dry-using-parameterized-inline-modules/7805 "2018-06-26T05:30:50Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![Centril](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/centril/32/3334_2.png) [@Centril](https://internals.rust-lang.org/u/Centril)\ **Post date:** [June 26, 2018, 5:30am UTC](https://internals.rust-lang.org/t/unbaked-idea-dry-using-parameterized-inline-modules/7805/1 "2018-06-26T05:30:50Z")
In a discussion about [RFC #2377, Item-level-blocks](https://github.com/rust-lang/rfcs/pull/2377), [@fknorr](https://github.com/rust-lang/rfcs/pull/2377#issuecomment-379214950) floated the idea of selling that RFC as "anonymous modules" which: > [..] has precedent with C++'s concept of anonymous namespaces, where `namespace {}` introduces an unnameable scope with the parent automatically importing all definitions. Syntactically, you would then write: ```rust #[cfg(debug_assertions)] mod { // ... } ``` On its own however, being able to write `mod { .. }` _just_ so that you may `#[cfg(debug_assertions)]` did not seem develop consensus. However, I have found another motivation for this syntax: not repeating type parameters. This idea is inspired by the `using (x : a, y : a, xs : Vect n a)` notation in [Idris](http://docs.idris-lang.org/en/latest/tutorial/typesfuns.html#using-notation). Simply put, we call `mod { .. }` an _inline module_ (IM), since all of its contents are _inlined_ into the enclosing scope. We then extend this with the ability to quantify and bound variables: ```rust mod<'a, T, U: Copy, const N: usize> { ... } ``` Items enclosed in this _parameterized inline module (PIM)_ are all prepended with the list of parameters in the `mod<...>`. A simple example: ```rust mod { fn foo() -> T { T::default() } } fn main() { assert_eq!(0, foo::()); } ``` This is imagined as primarily useful for generics heavy code that work within the same generic context over and over again. An example of this is [diesel](https://github.com/diesel-rs/diesel/blob/master/diesel/src/deserialize.rs), which [repeats](https://github.com/diesel-rs/diesel/blob/master/diesel/src/insertable.rs) `DB: Backend` over and over again... Some things to note: 1. `struct`s, `enum`s, `union`s and `impl`s, inside `mod<..>` must all use all the quantified parameters inside `mod<..>`. Otherwise, there are unused or unconstrained parameters, which Rust does not allow. 2. `static`s are _not_ allowed inside PIMs because doing so would introduce generic `static`s, which can cause soundness issues due to the same sequence of concrete types applied, at different places, to the generic `static` ending up with different addresses in memory. This is perhaps a fundamental limitation, but perhaps not. 3. This is one stop short of ML modules. Introducing those would be done by allowing you to name and quantify at the same time: `mod foo { .. }`. While being an interesting idea, this is not proposed at this time. It might however be that taste or expectation develops for those over time due to their inline cousins being added. 4. Implied bounds alleviate some of the problems PIMs are trying to solve, but not fully. 5. If people abuse this feature, by adding too many things in the PIM, understanding _can_ get harder, but this is not automatic. PIMs, like other current or would-be language features, are tools at your disposal, so use them tactfully. The same goes with cyclomatic complexity in `fn` bodies, overly complex types, and so on. 6. Prepending was chosen as the thing I thought was most obvious; but if there is consensus that Appending is more natural, I'm totally down with that. I don't have a strong feeling either way. 7. Is _inline_ in PIM the right word? Is _anonymous_ (PAM) more appropriate? Right now, this is a very unbaked idea. But I thought I'd spark a discussion. Thoughts? ---
**Author:** ![vorner](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/vorner/32/3310_2.png) [@vorner](https://internals.rust-lang.org/u/vorner)\ **Post date:** [June 26, 2018, 6:42am UTC](https://internals.rust-lang.org/t/unbaked-idea-dry-using-parameterized-inline-modules/7805/2 "2018-06-26T06:42:38Z")
To me, it looks quite logical extension, so it would depend on the details (eg. like things forbidden inside), but on the first glance it sounds good. In that sense, would it make sense to ask about a more generic thing? What everything in Rust has curly braces and what all annotations can be placed on them? If `mod` is the only thing that can’t have generic parameters, then it would make sense just for the consistency. And, does it really need to be a `mod { }`, or just a block/curly braces would be enough? These are mostly brainstorming ideas, just throwing them to the table to see where these could lead. About the name… if the items inside „spill“ to the parent namespace with all their modifiers (eg. `mod { pub struct Stuff }` is visible from outside the outer module), then inline is probably a better name. ---
**Author:** ![Centril](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/centril/32/3334_2.png) [@Centril](https://internals.rust-lang.org/u/Centril)\ **Post date:** [June 26, 2018, 7:07am UTC](https://internals.rust-lang.org/t/unbaked-idea-dry-using-parameterized-inline-modules/7805/3 "2018-06-26T07:07:23Z")
> [@vorner](#): > > on the first glance it sounds good. Great! > [@vorner](#): > > If `mod` is the only thing that can’t have generic parameters, then it would make sense just for the consistency. I believe this is the situation on that front: - `mod` can't have generic parameters (fixed in part by this ~proposal, but not for named `mod`s), - `static` can't have generic parameters -- for reasons I touched on before, - `const` can't have generic parameters, but you can have generic consts indirectly by use of inherent or trait impls. Changing this is not so hard I think and could be useful in the future. - `type` inside traits and impls can't have generic parameters (GATs fix this). - `extern` can't have generic parameters, and they shouldn't, because what does a generic FFI function mean? (this means that we have to disallow `extern { .. }` inside `mod { .. }` as well, or at least not let them reference the quantified parameters...). All other forms of items can have generic params, AFAIK. > [@vorner](#): > > And, does it really need to be a `mod { }` , or just a block/curly braces would be enough? So that would be ` { .. }`? Unless there is some syntactic ambiguity (none comes to mind), it should be technically feasible. But I feel as tho there should be something to hang the quantification on. Just having ` { .. }` feels a bit empty. Furthermore, `{ .. }` is not permitted at the top level at the moment. We could allow `mod { .. }` as a statement (we currently allow (named) modules inside `fn`), which means that you can do: ```rust fn foo() { mod { fn bar(x: T) -> T { x } } bar::(1); } ``` which is a boring example, but it was all I had time to think of ^,- If you want to quantify for lambdas and such, perhaps `for { .. }` should be considered as in?: ```rust let identity = for { |x: T| -> T { x } }; // or just: let identity = for |x: T| -> T { x }; ``` However, this possibly touches on RankNTypes which could be non-trivial to support. ---
**Author:** ![fbstj](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/fbstj/32/424_2.png) [@fbstj](https://internals.rust-lang.org/u/fbstj)\ **Post date:** [June 26, 2018, 7:50am UTC](https://internals.rust-lang.org/t/unbaked-idea-dry-using-parameterized-inline-modules/7805/4 "2018-06-26T07:50:51Z")
even more unbaked idea on top of this: could this be prototyped as a macro/plugin attached to the mod, which just applies/prepends the mod’s parameters to each of the members? and in a different vein, for the initial prototype would it be better to ‘enforce’ your first note and reduce any confusion of 6, by having ‘proxy’ generics. IE `mod { fn foo() -> T { T::default() } }` where the `foo`'s `T` is specifying the “location” of the `mod`'s `T`? ---
**Author:** ![Centril](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/centril/32/3334_2.png) [@Centril](https://internals.rust-lang.org/u/Centril)\ **Post date:** [June 26, 2018, 8:04am UTC](https://internals.rust-lang.org/t/unbaked-idea-dry-using-parameterized-inline-modules/7805/5 "2018-06-26T08:04:06Z")
> [@fbstj](#): > > even more unbaked idea on top of this: could this be prototyped as a macro/plugin attached to the mod, which just applies/prepends the mod’s parameters to each of the members? Probably? The complexity of such a macro depends on how far you take it... Do you also have to consider `fn` inside `fn` and such scenarios or is it just the immediate stuff inside `mod<..> { .. }`? > [@fbstj](#): > > and in a different vein, for the initial prototype would it be better to ‘enforce’ your first note and reduce any confusion of 6, by having ‘proxy’ generics. Sounds feasible; however, I would expect the binder in `fn foo` to shadow the first binder in `mod { .. }` wrt. `T`, so my hope is that that would remain a prototype but not the final thing. ---
**Author:** ![H2CO3](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/h2co3/32/2849_2.png) [@H2CO3](https://internals.rust-lang.org/u/H2CO3)\ **Post date:** [June 26, 2018, 10:08am UTC](https://internals.rust-lang.org/t/unbaked-idea-dry-using-parameterized-inline-modules/7805/6 "2018-06-26T10:08:56Z")
> [@vorner](#): > > does it really need to be a `mod { }` , or just a block/curly braces would be enough? I'd tend to say that yes, it should be `mod {}`, because a naked pair of curlies is already an expression in Rust, so even if it's not allowed at the top level (and so it doesn't technically cause syntactic ambiguity from the compiler's PoV), it might confuse programmers or at least look weird. Furthermore, one of the primary basis for "namespaces" in Rust are modules, not blocks, so I think `mod {}` would mesh better with that aspect of the language too. ---
**Author:** ![willi\_kappler](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/willi_kappler/32/2561_2.png) [@willi\_kappler](https://internals.rust-lang.org/u/willi_kappler)\ **Post date:** [June 26, 2018, 11:10am UTC](https://internals.rust-lang.org/t/unbaked-idea-dry-using-parameterized-inline-modules/7805/7 "2018-06-26T11:10:03Z")
I like the idea! Should your example be: ``` mod { fn foo() -> T { T::default() } } ``` That is `foo` instead of `foo` ? I think anonymous (PAM) modules is a better naming and `mod { }` should be used. This idea could be even extended to named modules, where a module takes one or multiple types as parameter. Inside the modules these type parameters are used as you describe them but the user is then allowed to have multiple instances of the same module: ``` use mod1 as m1; use mod1 as m2; m1::bar(); // u32 used here inside bar() m2::bar(); // bool used here inside bar() ``` Since you mentioned OCaml, IIRC they allow s.th. like this. But this would be a separate RFC (built on top of yours?). ---
**Author:** ![fbstj](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/fbstj/32/424_2.png) [@fbstj](https://internals.rust-lang.org/u/fbstj)\ **Post date:** [June 26, 2018, 11:59am UTC](https://internals.rust-lang.org/t/unbaked-idea-dry-using-parameterized-inline-modules/7805/8 "2018-06-26T11:59:33Z")
> That is `foo` instead of `foo` ? I believe the point is that the types attached to `mod<>` are 'implicitly' prepended to the parameter list when the mod is inlined into the parent module, so they only need to be defined in usage (outside? of the implicit/anonymous module) ---
**Author:** ![Ixrec](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/ixrec/32/6754_2.png) [@Ixrec](https://internals.rust-lang.org/u/Ixrec)\ **Post date:** [June 26, 2018, 1:47pm UTC](https://internals.rust-lang.org/t/unbaked-idea-dry-using-parameterized-inline-modules/7805/9 "2018-06-26T13:47:56Z")
I get the motivation for parameterized/generic modules, but what’s the motivation for also making them _anonymous_? In other words, why do we want this to be `mod { ... }` instead of `mod foo { ... } use foo::*;`, other than slightly less typing? Is it just to sidestep the awkward questions about how paths and imports work in the presence of named parameterized modules? ---
**Author:** ![elidupree](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/elidupree/32/4304_2.png) [@elidupree](https://internals.rust-lang.org/u/elidupree)\ **Post date:** [June 26, 2018, 1:51pm UTC](https://internals.rust-lang.org/t/unbaked-idea-dry-using-parameterized-inline-modules/7805/10 "2018-06-26T13:51:53Z")
I’d definitely appreciate the ability to elide a bunch of repeated generic parameters. It’s one of the things I missed from C++, where you can do: ```rust template struct scope { template struct first_object {… details that refer to foo, etc. …}; template struct second_object {… details that refer to foo, etc. …}; // no actual details for struct scope, it's only here to be a scope rather than a regular struct }; … typedef scope concrete_scope; typedef concrete_scope::first_object<…> concrete_first; typedef concrete_scope::second_object<…> concrete_second; ``` But this PIM syntax just doesn’t feel right to me, and it doesn’t fully match my use cases. - It’s a mod that’s not a mod? The way I see it, defining attributes of “mod” are making a privacy boundary and making paths distinct. This doesn’t do either of those things. So for this feature as described, I think it should be called something other than “mod”. - The automatic merging of the parameter lists also seems confusing. If you just looked at the type signature of foo where it appeared in the file, you’d write the wrong number of generic parameters and then be confused that the compiler was giving you errors for not giving enough generic parameters. (Good error messages could alleviate this a bit, but it still seems counterintuitive.) In particular, you could easily have a `fn foo` that USES a type parameter from the PIM, but only in its body, and doesn’t refer to that type in its signature, so there isn’t even a hint that you need to go look for the definition of that type. At first glance, I’d prefer having the 2 lists be separate, like the C++ way where you say `scope::specific_struct`. That seems pretty similar to a having explicit, named, parameterized modules. A related thing I miss from C++ is being able to define a struct inside a function and have it use the template parameters from the outer scope. In Rust, you have to make the inner struct be a generic struct that takes all of the parameters it needs. That’s another case of parameter list duplication. What’s the interaction between PIMs and structs defined inside a function? If those struct inherited the PIM parameters, that would prevent you from just making a regular one-off struct that’s useful for the function’s algorithm. So presumably, a struct defined inside a function inside a PIM would NOT inherit the parameters from the PIM, which makes such a struct even more second-class when you actually want to use the outer parameters. Let me see if I can come up with a variation on this feature that would meet my particular needs… ---
**Author:** ![Ixrec](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/ixrec/32/6754_2.png) [@Ixrec](https://internals.rust-lang.org/u/Ixrec)\ **Post date:** [June 26, 2018, 2:00pm UTC](https://internals.rust-lang.org/t/unbaked-idea-dry-using-parameterized-inline-modules/7805/11 "2018-06-26T14:00:08Z")
> [@elidupree](#): > > The automatic merging of the parameter lists also seems confusing. If you just looked at the type signature of foo where it appeared in the file, you’d write the wrong number of generic parameters and then be confused that the compiler was giving you errors for not giving enough generic parameters. (Good error messages could alleviate this a bit, but it still seems counterintuitive.) In particular, you could easily have a `fn foo` that USES a type parameter from the PIM, but only in its body, and doesn’t refer to that type in its signature, so there isn’t even a hint that you need to go look for the definition of that type. At first glance, I’d prefer having the 2 lists be separate, like the C++ way where you say `scope::specific_struct` . That seems pretty similar to a having explicit, named, parameterized modules. As long as we're [spitballing](https://internals.rust-lang.org/t/blog-post-proposal-for-a-staged-rfc-process/7766/24) syntaxes, here's a random thought: we could use an explicit `..`. ```rust mod { fn foo<..>() -> B { ... } fn bar<.., X>() -> X { ... } } ``` ---
**Author:** ![elidupree](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/elidupree/32/4304_2.png) [@elidupree](https://internals.rust-lang.org/u/elidupree)\ **Post date:** [June 26, 2018, 2:10pm UTC](https://internals.rust-lang.org/t/unbaked-idea-dry-using-parameterized-inline-modules/7805/12 "2018-06-26T14:10:03Z")
Oh, that’s a neat way to deal with the implicitness problem. Perhaps you would even be allowed to put the … in whatever position in the argument list you wanted. Although maybe standardizing it would make it easier to learn. ---
**Author:** ![hanna-kruppe](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/hanna-kruppe/32/6540_2.png) [@hanna-kruppe](https://internals.rust-lang.org/u/hanna-kruppe)\ **Post date:** [June 26, 2018, 2:11pm UTC](https://internals.rust-lang.org/t/unbaked-idea-dry-using-parameterized-inline-modules/7805/13 "2018-06-26T14:11:24Z")
The `mod<...> {}` syntax, and even the name “parametrized inline modules”, strongly suggests that this is the intersection of two separate features: 1. parametrized modules, where the module is named and the generic parameters are associated with it, rather than duplicated into all items inside the module 2. anonymous/inline modules, which splat their contained items into the parent module Having this feature but not those two would be pretty misleading and disappointing. So I’d really suggest painting the bikeshed a different color, unless we’re sure those two features or something similar will make it into the language too. ---
**Author:** ![elidupree](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/elidupree/32/4304_2.png) [@elidupree](https://internals.rust-lang.org/u/elidupree)\ **Post date:** [June 26, 2018, 2:23pm UTC](https://internals.rust-lang.org/t/unbaked-idea-dry-using-parameterized-inline-modules/7805/14 "2018-06-26T14:23:13Z")
Having thought about it for a bit, I think the feature I really want is explicit, named, parameterized modules. I’m thinking you’d declare `mod module_name`, and T would automatically become an item in inside module\_name, like it was a type alias that was explicitly written at the beginning of the module. (Why an item? Well, I’m thinking about when you have more submodules over multiple files. Submodules normally have to explicitly `use` things from their super, so it would be odd for this to be an exception.) There’s still a bit of an inconvenience. I often want to write logically-related pieces of code near each other in the same file, but if some of the logically-related functions DON’T depend on the outer generic parameters, then either I couldn’t write them in the same file, or you wouldn’t be able to use them without giving the module some explicit, arbitrary generic parameters. UNLESS the parameters of the module were somehow determined lazily(?) – i.e. you can import the module without specifying all of the generic parameters, and that’s permissible as long as you don’t actually USE any of the module’s descendants that refer to the parameters you didn’t specify. ---
**Author:** ![Ixrec](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/ixrec/32/6754_2.png) [@Ixrec](https://internals.rust-lang.org/u/Ixrec)\ **Post date:** [June 26, 2018, 2:40pm UTC](https://internals.rust-lang.org/t/unbaked-idea-dry-using-parameterized-inline-modules/7805/15 "2018-06-26T14:40:03Z")
It's probably worth mentioning that the main reason C++ has anonymous ~~modules~~ namespaces is because, by default, all top-level items in C++ have "external linkage"/are potentially visible to all other code in the program, so nowadays whenever you have an item that needs to be accessible to an entire file but isn't part of that file's public interface, you put it in an anonymous namespace to give it "internal linkage". Because Rust had `mod` and `pub` and was private-by-default on day 1, that motivation does not apply. * * * I also personally think we should try to solve the awkward path/import questions around named parameterized modules rather than bundle them up with anonymous modules to work around that. * * * > [@elidupree](#): > > I often want to write logically-related pieces of code near each other in the same file, but if some of the logically-related functions DON’T depend on the outer generic parameters, then either I couldn’t write them in the same file, or you wouldn’t be able to use them without giving the module some explicit, arbitrary generic parameters. With explicit `..` we could easily permit items in the module that lack the `..`. But this would still create an additional awkward wrinkle for the path/import questions. ---
**Author:** ![elidupree](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/elidupree/32/4304_2.png) [@elidupree](https://internals.rust-lang.org/u/elidupree)\ **Post date:** [June 26, 2018, 3:25pm UTC](https://internals.rust-lang.org/t/unbaked-idea-dry-using-parameterized-inline-modules/7805/16 "2018-06-26T15:25:17Z")
> [@Ixrec](#): > > With explicit `..` we could easily permit items in the module that lack the `..` . But this would still create an additional awkward wrinkle for the path/import questions. The `..` idea wouldn't work as-is with full parameterized modules, because you could have multiple nested modules that all have parameter lists, so you'd have to disambiguate which one the `..` referred to. I'm probably repeating previous design work here, but the way I imagined the parameterized module syntax is this: ```rust mod foo { pub fn bar(input: T) { println!("{}", input); } pub fn baz() { // does not use T or U } pub mod submodule { use super::U as Something; pub fn quux(something: & Something)->Something {something.clone()} } } use foo as first; use foo as second; use foo as third; // all parameters elided fn main() { // always legal because baz doesn't use the generic parameters first::baz(); second::baz(); third::baz(); // legal because T was specified first::bar (3i64); second::bar (3i32); // legal by inferring the generic parameter T, or maybe just a compile error if inferring is too confusing third::bar (3i16); // definitely compile error because it over-constrains the generic parameter T third::bar (5.0f64); // compile error because it infers U = NotClone and that doesn't meet the bounds struct NotClone; second::submodule::quux(NotClone); } ``` ---
**Author:** ![Tom-Phinney](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/tom-phinney/32/3299_2.png) [@Tom-Phinney](https://internals.rust-lang.org/u/Tom-Phinney)\ **Post date:** [June 26, 2018, 4:49pm UTC](https://internals.rust-lang.org/t/unbaked-idea-dry-using-parameterized-inline-modules/7805/17 "2018-06-26T16:49:54Z")
Just a meta note: The term “[brainstorming](https://en.wikipedia.org/wiki/Brainstorming)” really is the appropriate description for the prior posts in this thread. ---
**Author:** ![mcy](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/mcy/32/6512_2.png) [@mcy](https://internals.rust-lang.org/u/mcy)\ **Post date:** [June 26, 2018, 6:11pm UTC](https://internals.rust-lang.org/t/unbaked-idea-dry-using-parameterized-inline-modules/7805/18 "2018-06-26T18:11:09Z")
I really don’t like the “implicit prepending” idea. Something I’d be more comfortable with would be the following strawman: ```rust mod foo<'a, A: Tr1> { fn bar() -> Baz<'a, A, B> { .. } } // .. foo::<'static, i32>::bar::(); // or something like fn bonk<'a, T: Tr1>(&'a T) { use crate::foo::<'a, T>; foo::bar::(); // or maybe even: use crate::foo::<'a, T>::bar; bar::(): } ``` Basically, I don’t want `mod <..>` to be a shorthand for repeated type parameters. If you want to use it, you have to parameterize the module, not its contents. If you want to expose the concatenated version, I imagine you could do ```rust mod foo { fn bar() { .. } } // re-export `bar` with the module's // parameters prepended pub use foo<..>::bar; bar::(); ``` Also, if we allow this sort of syntax, I suppose we’d need to allow general concretization in _all_ `use` statements, so you could do silly things like ```rust pub use std::Box as MyBox; ``` and oh my god I’ve basically replicated C++'s templated `using` what have I done I might as well just say that nonsense like `pub use &'_ _ as MyRef` is allowed. ---
**Author:** ![mcy](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/mcy/32/6512_2.png) [@mcy](https://internals.rust-lang.org/u/mcy)\ **Post date:** [June 26, 2018, 7:12pm UTC](https://internals.rust-lang.org/t/unbaked-idea-dry-using-parameterized-inline-modules/7805/19 "2018-06-26T19:12:34Z")
After a little more thinking, since we’re throwing around silly ideas, here is an unfiltered idea that hasn’t even had the yeast added: In general, `` becomes a true path component, which in a lot of situations it’s sorta like that: in my slightly more reasonable proposal, if you have path to module `path::to::foo`, you need to include type parameters with a turbofish before you can access its contents: `path::to::foo`, or you can write `path::to::foo::<..>` to delay application of the arguments further down the chain. What if instead we allow something like ```rust mod foo { fn bar() {} } use self::foo::<..>::*; // the type parameters are forwarded, // but now there's two parameter lists! bar::::(); // or even allow multiple type parameter lists fn baz() {} baz::::(); // useful for HKTs without type closures! struct Foo<'a>; fn foo>() {} foo::>(); // instead of foo::<|X| Foo<'a>>(); // even more nonsensical: mod foo { mod bar { fn baz(); } } use self::foo::<..>::bar::<..>::baz; baz::::::(); ``` This gives us a vaguely sane way to do inline modules: ```rust mod foo { mod { fn bar() {} } static BAZ ..; } self::foo::::bar::(); self::foo::BAZ = 0; use self::foo::<..>::bar; bar::::(); ``` Feel free to take all of this with a grain of salt. I just had this idea and I’m pretty sure most of what I’m suggesting is terrible for readability. Especially the type-currying part. Edit: Alternative, more reasonable(?) syntax for “forwarding” generic parameters: ```rust use self::foo::<*>::bar; ``` By analogy with `*`, we’re importing _all_ possible parameterizations of `foo`, though I think this makes around as much sense as `use foo::*::bar;`… but this entire reply is off-the-rails brainstorming. ---
**Author:** ![willi\_kappler](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/willi_kappler/32/2561_2.png) [@willi\_kappler](https://internals.rust-lang.org/u/willi_kappler)\ **Post date:** [June 27, 2018, 6:55am UTC](https://internals.rust-lang.org/t/unbaked-idea-dry-using-parameterized-inline-modules/7805/20 "2018-06-27T06:55:31Z")
Right, that’s the whole point! Sorry for the noise I was thinking of s.th. different… [Next page](https://internals.rust-lang.org/t/unbaked-idea-dry-using-parameterized-inline-modules/7805.md?page=2)