Incorporating functions in Rust lang/prelude with clashing function name with a dependency crate in cargo toml

[arnabanimesh]

I have some suggestions as to how to go about incorporating functions with the same function name as that of a dependency crate in order to prevent conflicts.

rust-lang/rust#79524 has inspired me to create this RFC.

My suggestion goes something like this:

1. Add a flag to Cargo.toml to load std functions before dependency functions which is by default added for new rust versions (personally I would want to include it as a feature of a new Rust edition, but since 2021 got released just now I am not so sure) even if the user declares to use the dependency crate globally unless the user marks it as something like !important or priority use
2. If there is a function with the same name in the std lib as that of dependency, and if the stdlib function is used clippy should show a warning. Needless to say if any error occurs while compiling, proper source of the function should be made evident in the error messages.
3. All of this is not required if the dependency crate is not called upon in the Cargo.toml

[Nytelife26]

It seems more sensible to me to use the libstd / libcore version unless there is another clashing implementation or imported function in an external dependency, but in a warning. That way already existing crates that use external dependencies with overrides will issue a warning to make people aware there is a conflict, but they will also still compile and work as intended. This will minimise unexpected behaviour resulting from std functions potentially differing in implementations compared with imported functions; when someone imports something, they're likely expecting that to get used.

This shouldn't change the logic for conflicting names that don't involve libstd / libcore, though - that should still be a full error. Also, if the conflicting version from libstd / libcore is imported alongside an external version, it should be an error, since in that case there is no way to safely assume what the user wants.

[arnabanimesh]

@Nytelife26 it is a good approach provided that the added function in the prelude works in the same way (mostly similar) as the conflicting dependency function name otherwise the warning may annoy some. Nonetheless I like this approach.

[nanoqsh]

Notice what Itertools requires Iterator: pub trait Itertools: Iterator. This can be used to determine the order in which names are resolved. For example, let the compiler allow you to "override" a trait method, but usage of this:

• As .intersperse(..) will cause a warning and calls "overrided" method for the backward compatibility.
• As Itertools::intersperse(..) or Iterator::intersperse(..) will work as usual.

But #[deprecated] attribute on Itertools::intersperse gives priority to the parent and removes the warning.

This approach is good because it doesn't use Cargo and the fact that one crate is more basic (like std) than another. The fact that one trait depends on another is used instead, which can be used even within one crate