RFC: Allow a module to export other items with same name

[nikomatsakis]

Right now, there is no convenient way to define a module like option, that both defines a type and several accessors. You end up defining a type t and then writing option::t, which is unfortunate. So unfortunate, it seems, that we hacked around this particular case in the core library.

Perhaps we could allow a special form of export that lets a module define the other namespaces associated with its name. So, for example, option could be defined as:

export t as mod;
enum t<A> { some(A), none }
fn foo() { ... }

Now if I do import option, the name option refers to the module option but also to the type option::t. You would be permitted one "as mod" export for each namespace other than module (values, types, impls?).

@pcwalton preferred as self as the syntax, but I don't think self is currently a keyword, so I substituted mod.

[nikomatsakis]

Reading it again, as self does seem to read better. as mod sounds like you are making it a module.

[beoran]

How about using "export t as type;", since it's a type that gets exported? You could then do likewise for impls: "export TImpl as impl;", etc.

[nikomatsakis]

the question is not what kind of thing it is, but the name. export t from a module m exports the name m::t. export t as self would "export" the type namespace for the name m, so that using m as a type would yield the type m::t, basically. So basically export t as type doesn't sound to me like what it's doing.

[beoran]

OK, I see, point taken about that it's not what kind of thing it is.

But I still feel the need to paint the bikeshed a bit, and I think that both export t as self or export t as mod sound a bit clumsy and non-intuitive. If the point is that using m as a type should yield the type m::t, then I think export t as type makes the most sense. It seems logical to me that to use the type keyword when exporting a type as the "exported type" of a module.

[nikomatsakis]

One thing that worries me is that I find it hard to even explain the idea. That is, when I write out how it works I find it hard to say it very precisely except by example. Maybe that's a bad sign.

[beoran]

Well; this is how I would put it in text, as I understand it.

Every module can optionally export a type as it's master type. When the module is imported and referred to in a type context, then this referral is interpreted as being the master type of that module.

The master type thing could bereplaced by self type module type eigentype ,etc, whatever good term you can think of. But perhaps you're right that this sounds rather complicated. What is actually the reason for the use of module::t convention? Could it not be replaced with a different convention?

[ssylvan]

Here's an idea: just declare the type with the same name as the module name. That means you'd have to say option::option unless you imported "option::*" or something. However, now add an option on the exporter side to "bubble up" a type one namespace level, effectively putting that type's name at the same namespace level as the containing module.

E.g.

mod foo
{
          export sometype promoted; // not serious about the 'promoted' keyword, drawing a blank
          enum sometype { /*...*/ };
}

If another module then just imports foo, you can use foo as a module to refer to other items within it, but sometype is also available unqualified because of the special "promote" modifier which puts it at the same level as foo.

That lets you define a type "option" inside the module "option", but without the special case that you can only have one "self type". Any data type can be lifted up to be "equal" to its containing module, w.r.t. the namespace hierarchy.

[ssylvan]

Although tbh, an acceptable solution (IMO) is to just stop using data types called "t" and just give it a descriptive name. If the module name and datatype name happens to be the same, then so be it. After all, you can just "import option::*".

[nikomatsakis]

I agree we should call the type after the module, but I'd rather not encourage ::* imports, as they make the code harder to read. But maybe the cure is worse than the disease.

[beoran]

Ok, so, what's wrong then with having to say import option::option? If I'm not mistaken, if we do this, we can use option as the type we need right? It looks to me like the problem with the option::t convention is that you can't use it with import correctly.
Maybe we could simply adopt the convention that the name of the "master type" of a module (as I called it before) should be the same as that of the module, and that the user has to use import modulename::modulename to use that type. For a programming language, sometimes sensible conventions are better than complex features.

[nikomatsakis]

Yeah, that's kind of what I meant by "the cure is worse than the disease." It's not that painful.

It gets somewhat more painful if what you want is buried somewhere. For example, to use std::list::list nicely, I guess you would need:

import std::list;
import list::list;

[beoran]

Another possibility could be to play with capital letters?

import std::list;
import list::List;
// or 
import std::list::List;

[graydon]

I think this mostly shows up in one "serious" case, which is when a module is a "manager" for a datatype (in the old AST-literature sense). The easiest way to handle that is to put import list::list; in std. Then when a client does import std::list they get both the module std::list and the type std::list::list usable as the bare name list, disambiguated by context.

[nikomatsakis]

Yeah, that's the case we were thinking of. We were hoping to find something a bit less "one off" than the solution you described---i.e., something easier to do for user-defined modules and so forth.

[graydon]

Hm? It'll work exactly the same when you have user-defined modules. Your user-defined module lives in a crate, right? So re-import a typename from your user-defined module up to the crate root as well.