Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC: `self` in `use` #532

Merged
merged 1 commit into from Dec 31, 2014

Conversation

Projects
None yet
10 participants
@lifthrasiir
Copy link
Contributor

commented Dec 19, 2014

Proposes the mod keyword used to refer the immediate parent namespace in use items (use a::b::{mod, c}) to be changed to self.

Rendered

RFC: `self` in `use`
This proposes the `mod` keyword used to refer the immediate parent namespace
in `use` items (`use a:🅱️:{mod, c}`) to be changed to `self`.
@P1start

This comment has been minimized.

Copy link
Contributor

commented Dec 19, 2014

For reference, here is the rationale given for mod rather than self on the original RFC (#108):

[…] we prefer using mod to using self since self is heavily overloaded already, can be bound as an identifier as well as a keyword, and would have different meanings in a use item depending on if it occurred at the start of the path or in braces at the end of the path.

I don’t quite understand the reasoning of the the last point above: self::foo is equivalent to foo, so it makes sense for foo::{self, bar} to be equivalent to foo and foo::bar.

@lifthrasiir

This comment has been minimized.

Copy link
Contributor Author

commented Dec 19, 2014

@P1start Thank you for the pointer, I thought #168 was the original RFC proposed. This still does not really change the points listed in this RFC, I think.

@liigo

This comment has been minimized.

Copy link
Contributor

commented Dec 19, 2014

self +1, things have changed, after last issue which we introduce mod in
use: enum variants are namespaced now.

@blaenk

This comment has been minimized.

Copy link
Contributor

commented Dec 19, 2014

Despite knowing enum variants are namespaced, I hadn't recognized the inconsistency with using mod. I think this is an OK change in my opinion, for the sake of consistency, but it's not something I think is entirely crucial. It could be more important if it's possible that we could have more namespacing occurring in the future at non-module levels, as with enums most recently.

@erickt

This comment has been minimized.

Copy link

commented Dec 20, 2014

I think this makes sense given the enum namespace argument.

@Kimundi

This comment has been minimized.

Copy link
Member

commented Dec 20, 2014

Also, for importing associated items in general:

use std::clone::Clone::{self, clone};
@brendanzab

This comment has been minimized.

Copy link
Member

commented Dec 21, 2014

+1 to this.

@cmr

This comment has been minimized.

Copy link
Member

commented Dec 22, 2014

This does seem sensible, even before enum namespacing, in the general case a namespace didn't correspond to a module (you just couldn't do much with such a path, because UFCS wasn't a thing).

@nrc nrc self-assigned this Dec 30, 2014

@nrc

This comment has been minimized.

Copy link
Member

commented Dec 31, 2014

We discussed this in today's meeting and approve, merging.

Tracking issue

@nrc nrc merged commit 496ea64 into rust-lang:master Dec 31, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.