Unbaked Idea: DRY using "parameterized inline modules"

[Centril]

on the first glance it sounds good.

Great!

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 mods),
• 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<T> { .. } as well, or at least not let them reference the quantified parameters…).

All other forms of items can have generic params, AFAIK.

And, does it really need to be a mod { } , or just a block/curly braces would be enough?

So that would be <T, const N: usize> { .. }? 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 <T, U> { .. } 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:

fn foo() {
    mod<T> {
        fn bar(x: T) -> T { x }
    }

    bar::<usize>(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<T> { .. } should be considered as in?:

let identity = for<T> { |x: T| -> T { x } };
// or just:
let identity = for<T> |x: T| -> T { x };

However, this possibly touches on RankNTypes which could be non-trivial to support.

[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?

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<T: Default> { fn foo<T,U>() -> T { T::default() } } where the foo's T is specifying the “location” of the mod's T?

[Centril]

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<..> { .. }?

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<T, U> to shadow the first binder in mod<T: Default> { .. } wrt. T, so my hope is that that would remain a prototype but not the final thing.

[H2CO3]

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.

[willi_kappler]

I like the idea! Should your example be:

mod<T: Default> {
    fn foo<T, U>() -> T { T::default() }
}

That is foo<T, U> instead of foo<U> ?

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<u32> as m1;
use mod1<bool> 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?).

[fbstj]

That is foo<T, U> instead of foo<U> ?

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)

[Ixrec]

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<T> { ... } instead of mod foo<T> { ... } 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?

[elidupree]

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:

template <typename foo, bunch of other template parameters> struct scope {
  template <typename bar> struct first_object {… details that refer to foo, etc. …};
  template <typename baz> 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<uint64_t,…> 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<parameters>::specific_struct<parameters>. 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…

[Ixrec]

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<parameters>::specific_struct<parameters> . That seems pretty similar to a having explicit, named, parameterized modules.

As long as we’re spitballing syntaxes, here’s a random thought: we could use an explicit ...

mod<A, B, C> {
    fn foo<..>() -> B { ... }
    fn bar<.., X>() -> X { ... }
}

[elidupree]

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.

[rkruppe]

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.

[elidupree]

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<T: Trait, …>, 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.

[Ixrec]

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.

---

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.

[elidupree]

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:

mod foo<T: Display, U: Clone> {
  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<i64, u32> as first;
use foo<i32,_> 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);
}

[Tom-Phinney]

Just a meta note: The term “brainstorming” really is the appropriate description for the prior posts in this thread.

[drXor]

I really don’t like the “implicit prepending” idea. Something I’d be more comfortable with would be the following strawman:

mod foo<'a, A: Tr1> {
    fn bar<B: Tr2>() -> Baz<'a, A, B> { .. }
}
// ..
foo::<'static, i32>::bar::<f32>();
// or something like
fn bonk<'a, T: Tr1>(&'a T) {
    use crate::foo::<'a, T>;
    foo::bar::<f32>();

    // or maybe even:
    use crate::foo::<'a, T>::bar;
    bar::<f32>():
}

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

mod foo<T> {
    fn bar<U>() { .. }
}

// re-export `bar` with the module's 
// parameters prepended
pub use foo<..>::bar;

bar::<T, U>();

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

pub use std::Box<FnOnce()> 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.

[drXor]

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, <T, ..> 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<T>, or you can write path::to::foo::<..> to delay application of the arguments further down the chain. What if instead we allow something like

mod foo<T> {
    fn bar<U>() {} 
}

use self::foo::<..>::*;

// the type parameters are forwarded,
// but now there's two parameter lists!
bar::<T>::<U>();

// or even allow multiple type parameter lists
fn baz<T><U>() {}
baz::<T>::<U>();

// useful for HKTs without type closures!
struct Foo<'a><A>;
fn foo<T<_>>() {}
foo::<Foo<'a>>(); // instead of
foo::<|X| Foo<'a><X>>();

// even more nonsensical:
mod foo<T> {
    mod bar<U> {
        fn baz<V>();
    }
}

use self::foo::<..>::bar::<..>::baz;
baz::<T>::<U>::<V>();

This gives us a vaguely sane way to do inline modules:

mod foo {
    mod<T> {
        fn bar<U>() {}
    }
    static BAZ ..;
}

self::foo::<T>::bar::<U>();
self::foo::BAZ = 0;

use self::foo::<..>::bar;
bar::<T>::<U>();

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:

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.

[willi_kappler]

Right, that’s the whole point! Sorry for the noise I was thinking of s.th. different…

[jdm]

This is a feature that I’ve been longing for as part of the massive crate splitting effort being prototyped in Servo right now as a summer of code project. This branch involves replicating the same trait bounds throughout hundreds of structs and functions in a giant crate, and reducing that number would be a huge help. I always imagined it a bit like how closures capture specific parts of their environment - if the compiler came across an undeclared type name, it could look in the enclosing module for any matching generic type and silently use that.

[system]

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