It prevents ambiguities. If you have a type that implements two traits, and those traits have methods with the same name, which one do you choose? By importing the trait, the users specifies which one to use. If you need to use both traits in the same scope, there is a way to disambiguate, but it isn’t very ergonomic.
Now imagine you have code that works using one trait, and at a later time you implement another trait with the same method names. If the import wasn’t required, it would silently introduce the ambiguity to the whole crate and break code that was working before and is potentially totally unrelated.
I think that nobody mentioned such topics if Rust provides a statement to enable methods of a trait for statically dispatches without importing the trait name into scope.
Another example is about uniqueness of trait names. In my understanding, it’s recommended to use unique names for types in Rust (I know this is rather a general programming manner which is also applicable to other programing languages).
I agree with this, and this is more important in Rust than other languages. Because Rust requires to import traits into scope for statically dispatches. In the meantime, this recommendation decreases efficiency of module names as namespaces.
I know that there is no perfect programming language. And I just want to know fundamental philosophy in Rust for writing better code.
I think that it’s generally possible to distinguish traits having the same name without importing the name into scope, technically. Because each trait have its own fully qualified name like mod1::Trait and mod2::Trait.
My concern was why Rust decided not to separate the following functions of use mod::Trait into two statements:
importing the trait name Trait into scope
enabling methods of Trait for statically dispatches
My image is like below:
// imports the name `Trait` into scope, but doesn't enable method of Trait for statically dispatches
// enables methods of Trait for statically dispatches without import the name `Trait` into scope