We should drop `type` and make `use` replace it like C++'s `using`

internals bikeshed (deprecated)
1

Frees up a keyword, use already sorta declares aliases for things, what’s not to love.

1 Like
2

type and use do different things. We can’t just drop type.

3

Yes, I’d expect that use needs to basically accept type parameters on either side of the =, and people might need to specify self:: a bunch. Am I missing something else?

4

use can’t do that. It imports paths into scope. It doesn’t make any sense to have a type parameter on either side of the import. The only difference a pub makes in pub use is that it re-exports the just-imported path from the current module. But it does not change the semantics of importing the path.

5

I understand it can’t currently do that. I’m arguing that eg.

    use MyNameForString = std::string::String;

and

    type MyNameForString = std::string::String;

are overlapping enough in purpose that it, imo, makes enough sense to unify the two constructs rather than have both of them do “subtly” different things.

6

@benh a seemingly minor detail: Would you also continue to restrict such type use's to only appear at the start of the block, just like all view items are restricted today?

Or are you proposing that use's be allowed to be interspersed, solely in this case?

Or are you proposing that all view items be allowed to be interspersed in the block?

7

they would definitely need to specify self:: a bunch. The fact that the right-hand side of use is resolved relative to the crate-root while the right-hand side of type is resolved relative to the current block is a significant difference between them, not something to be glossed over.

Consider for example the following:

fn main() {
    // Below `use` does not work for this case;
    // `self` in a path refers to a module,
    // not to a function body's scope.

    // use self::Foo;

    #[deriving(Show)]
    struct Foo;
    type Bar = Foo;

    fn bar(b: Bar) {
        println!("Bar: {}", b);
    }

    bar(Foo);
}
8

I suppose this depends on what import shadowing rules we end up with. I was in the frame of mind of kimundi’s rfc to disallow shadowing that suggests an rfc to remove the ordering restrictions as a next step.

9

Right, I certainly missed the case where you’d have a function-local variety of items and aliases… the combination of items with no absolute path + absolute-path-only use items is exacerbated by my proposal here. Alas.

10

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