Consider a module that wants to use trait methods from both std::fmt::Write
and std::io::Write
(via write!
or writeln!
), and thus needs to import both. For anything other than a trait, it would work to use std::fmt;
and use std::io;
and then refer to the qualified names fmt::Write
and io::Write
. However, using the methods of a trait requires importing that trait directly, necessitating a rename:
use std::fmt::Write as FmtWrite;
use std::io::Write as IoWrite;
This applies even if the module will never use those names, and only wants to call trait methods like write_fmt
.
Iâd like to propose changing the compiler to allow importing names that conflict without producing an error, and only emitting an error if code uses the names ambiguously. For instance, the following would work:
use std::fmt::{self, Write};
use std::io::{self, Write};
impl io::Write for ... { ... }
...
try!(writeln!(...));
But the following code would produce an error:
use std::fmt::{self, Write};
use std::io::{self, Write};
impl Write for ... { ... }
The error message would look roughly like this:
error[E0405]: trait name `Write` ambiguous
--> <anon>:1:6
|
1 | impl Write for u32 {
| ^^^^^ `Write` is ambiguous
|
= help: Use one of the following qualified names:
= help: `fmt::Write`
= help: `io::Write`
In practice, this would only apply to trait names, since any other name never referenced directly would produce a warning about the unused import. Iâd have no objection to the compiler continuing to detect name conflicts on non-traits early, and only deferring name conflicts for traits.
Does this seem reasonable?