RFC: self in use

[lifthrasiir]

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

[ftxqxd]

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]

@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]

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

[blaenk]

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]

I think this makes sense given the enum namespace argument.

[Kimundi]

Also, for importing associated items in general:

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

[brendanzab]

+1 to this.

[emberian]

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]

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

Tracking issue