Inherit use

[emberian]

No description provided.

[lilyball]

This sounds like a reasonable idea. What about extern crates? Those are only in-scope in the crate file. Would we have inherit extern crate foo;? Saying inherit use foo; won't work because use foo; is illegal in the crate file (although I'm not really sure why).

[thestinger]

I haven't decided if I like or dislike this idea, but I think it would be better to use an attribute like #[inherit] here since it will only ever occur on a top-level item. It's sad to lose so many useful identifiers to keywords.

[dobkeratops]

It's sad to lose so many useful identifiers to keywords.

my variation of this suggestion would have been

• inherit is actually the default;
• 'priv' recovers the current behaviour. (priv was already reserved).

i would guess 'inherit' as default wouldn't be a problem in terms of 'over-visibility', wouldn't the more 'fine-grain' use's be further down the module graph anyway; and if you really need isolation/decoupling of a module for re-useability, you can make a crate instead

[emberian]

I'm not sure if I like using attributes for something as fundamental as
this, but I'm not against it. I certainly prefer it to using this keyword.
I don't want it to be the default because I very much like being able to
see what is in scope by looking up.

On Tue, Apr 8, 2014 at 5:16 AM, dobkeratops [email protected]:

It's sad to lose so many useful identifiers to keywords.

my variation of this suggestion would have been

• inherit is actually the default;
• 'priv' recovers the current behaviour. (priv was already reserved).

i would guess 'inherit' as default wouldn't be a problem in terms of
'over-visibility', wouldn't the more 'fine-grain' use's be further down the
module graph anyway

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/38#issuecomment-39827253
.

http://octayn.net/

[flaper87]

s/can//?

[flaper87]

I'm in the same position as @thestinger I'm not sure whether I like it or not, although it seems useful. I'll put more thoughts on this.

[lilyball]

I don't like losing keywords either. Maybe it's time we start introducing context-sensitive keywords?

[nrc]

As far as the keyword goes, I don't like inherit much since it implies to me that the thing is inherited into the current scope rather than that it is inherited from the current scope. I suggest virtual or abstract because they are often used to mean may be inherited from - although that is also not quite what we want. virtual has the advantage that it is (will be) used elsewhere and so we don't lose a keyword.

[emberian]

"virtual use" and "abstract use" sound terrible and are meaningless, to me.
I think it should probably just be an attribute, thus sidestepping the
keyword issue entirely.

On Tue, Apr 8, 2014 at 3:42 PM, Nick Cameron [email protected]:

As far as the keyword goes, I don't like inherit much since it implies to
me that the thing is inherited into the current scope rather than that it
is inherited from the current scope. I suggest virtual or abstractbecause they are often used to mean may be inherited from - although that
is also not quite what we want. virtual has the advantage that it is
(will be) used elsewhere and so we don't lose a keyword.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/38#issuecomment-39892637
.

http://octayn.net/

[dobkeratops]

i was going to suggest 'super use' , even though its kind of the opposeite of super's meaning in scope.
Or perhaps you could use symbols like .. * or braces somehow eg
use{..} foo::bar" . use in downstream scopes..
use.. foo::bar
use in* foo::bar
use in{} foo::bar
or do those just look like typos :)

[olsonjeffery]

#[heritable]

On Tuesday, April 8, 2014, dobkeratops [email protected] wrote:

i was going to suggest 'super use' , even though its kind of the opposeite
of super's meaning in scope

Reply to this email directly or view it on GitHubhttps://github.com//pull/38#issuecomment-39895240
.

[esummers]

As far as the keyword goes, I don't like inherit much since it implies to me that the thing is inherited into the current scope rather than that it is inherited from the current scope. I suggest virtual or abstract because they are often used to mean may be inherited from - although that is also not quite what we want. virtual has the advantage that it is (will be) used elsewhere and so we don't lose a keyword.

@nick29581 What about cascade for the keyword or attribute?

[emberian]

cascade is something I could get behind.

On Tue, Apr 8, 2014 at 7:45 PM, Eric Summers [email protected]:

As far as the keyword goes, I don't like inherit much since it implies to
me that the thing is inherited into the current scope rather than that it
is inherited from the current scope. I suggest virtual or abstract because
they are often used to mean may be inherited from - although that is also
not quite what we want. virtual has the advantage that it is (will be) used
elsewhere and so we don't lose a keyword.

What about cascade for the keyword or attribute?

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/38#issuecomment-39914933
.

http://octayn.net/

[dobkeratops]

are glob imports still buggy.. does 'use super::*' bypass the need for inherit use? is it too "indiscriminate" ? I dont think it would be any harder to teach or more cluttering, vs another keyword.

[lilyball]

It seems a bit indiscriminate. It will pull in everything from super, not just the use declarations. And in fact it won't even pull in non-pub use declarations, so it won't even do what is being suggested here.

I could see turning this around and having it be some #![inherit_use] attribute on the child module that says it should inherit its parent's use statements. Although the one problem I can see with that is the parent may be able to use something that the child can't, due to privacy rules. This also is less fine-grained, in that it would pull in all use statements, not just the ones the parent wanted to share.

Thinking about this RFC a bit more, my biggest concern is that this makes it harder to figure out where a name came from in a child module. Normally you can just search the file to find the top element of any referenced path (with globs being the only exception, but that's feature-gated), but this proposal decouples it so you have to look outside the current module up to all the parents. I don't know how important this actually is, though. And it's not even a strict rule today; macros (and syntax extensions) don't have corresponding use statements, but those are special invocations and therefore their special scoping may be irrelevant.

Of course, if we do plan on un-feature-gating globs at some point, then this becomes much less of an issue. I don't know what the long-term plan there is.

[dobkeratops]

so at the minute the 'common.rs' use common::* is the best way to get a load of common uses i guess,
i suppose we can put a mod common in our cratefile, which saves having another file . That doesn't actually seem as bad, wheras common.rs brings back memories of precompiled headers and so on in c++ :)

[bstrie]

Consider myself among those who are concerned about rampant keyword proliferation. I'm not sure this is entirely warranted (hooraaaay, more complexity in the module system!), but if it is, let's do it via an attribute if possible.

That said, I'm more interested by #37, if that would obviate the desire for this.

[emberian]

I'm more in favor of #37 than this, but I think this is also useful.

[alexcrichton]

Closing as postponed, we think that something like this can be added backwards compatibly.

[glaebhoerl]

Adding my thoughts here because they're not well-developed enough yet to warrant a separate discussion:

Just in terms of basic intuition, I naturally expect inner scopes ({ this is a scope }) within a single file to be able to see the things from outer scopes. This is true inside function bodies, and, except for mods, I think it's true for all other constructs in Rust. It's also how inner classes and inner namespaces work in C++. However, in a given file, I would be very surprised to have things implicitly in scope from a different file.

I.e., to illustrate:

// mod_a.rs
static MY_NUM: uint = 42;
mod mod_b {
    // would expect MY_NUM to be in scope
}
mod mod_c;

// mod_c.rs
// would *not* expect MY_NUM to be in scope

The direct, worse-is-better approach would be to just go ahead and make it so: modules get to see definitions from ancestor modules within (and only within) the same file. However, I don't think the module system itself has any logical concept of "a file", only the implementation does.

So a slightly more sophisticated answer would be to have two different kinds of modules, those which see definitions from outer scopes, and those which don't. For the sake of discussion (I don't really like these names), call them open mod and plain mod (which is closed, as today). And modules defined in separate files are always closed modules, while those defined inline in the same file can be declared either open or closed. Which is basically similar to what @kballard suggested.

Although the one problem I can see with that is the parent may be able to use something that the child can't, due to privacy rules.

Is this even possible? I don't think it is. Or should be.