I hope that the trait methods can be directly imported, to prevent confusion

language design
1

For now, use some_mod::SomeTrait; will import all the methods in the trait, which may encounter 'strange identifiers', which is also a tough complexity in other programming languages.

// This mod may be defined at another file, or even another crate.
// But to describe the problem more easily, I put the content inline.
mod some_mod {
    use std::fmt;

    pub trait Foo {
        fn bar(&self) where Self: fmt::Display {
            println!("Processing {self}");
        }
    }

    impl Foo for str {}

}

// Zillions of usage lines, sinking out the definitions below.
use crate::some_mod::Foo; // This line is probably ignored by the programmer who looks for the ".bar()" method, since Foo is quite different from bar.
// Squillions of usage lines, sinking out the definitions above.

// If the below is avalible:
// use crate::some_mod::Foo::bar; // Excellent! I've found the method ".bar()" is here!
// it will be quite better.
// but for now, it will cause: 
// error[E0253]: `bar` is not directly importable

fn main() {
    // "Oh no! Where is the method "bar"? I can't find it!", another programmer says.
    "hello".bar();
}
2

I'm not sure I'd call this a good solution, but it seems like the compiler is willing to tell you if you ask nicely:

    // "Oh no! Where is the method "bar"? I can't find it!", another programmer says.
    // Add this dummy function, to see candidates for `bar`
    fn check<T>(t: T) { t.bar() }
    "hello".bar()
}

Compiler output:

error[E0599]: no method named `bar` found for type parameter `T` in the current scope
  --> src/main.rs:29:27
   |
29 |     fn check<T>(t: T) { t.bar() }
   |              -            ^^^ method not found in `T`
   |              |
   |              method `bar` not found for this type parameter
   |
   = help: items from traits can only be used if the type parameter is bounded by the trait
help: the following trait defines an item `bar`, perhaps you need to restrict type parameter `T` with it:
   |
29 |     fn check<T: Foo>(t: T) { t.bar() }
   |               +++++

For more information about this error, try `rustc --explain E0599`.
3 Likes
3

Yeah, it does work, but only for small projects. But in large projects, the code readers still cannot directly tell where the method is from.

4

Does the go-to-definition from Rust Analyzer not work for finding where these methods come from for you? I use it pretty regularly and it works well for me.

5

I think that there may be a use-case for importing some of the methods of a trait but not others – if a type implements two traits and some of them have clashing names, it would be helpful to be able to import the names of trait methods individually so as to avoid the clash. (This situation could happen by accident if importing two unrelated crates.) I'm not sure how often that's an issue in practice, though (there are some serious clashes between methods of std::io::Write and std::fmt::Write but that's probably intentional as they don't seem designed to both be implemented by the same type).