> FWIW I personally think 5 possible matches is potentially already too much if you're a newcomer to a language or even just a large project.
I'm... not sure what you'd want to happen when there are literally 5 methods called write_u16, how is a general-purpose search to know which one you're looking for without more information? If you want contextual matching... use an IDE (or hook rust-analyser into your editor of preference).
(also there are way more than 5 matches in total as there are methods like `write_u16_into` which would also match at a lower rank).
Without ad-hoc polymorphism and with explicit exports the correct one must have been disambiguated in import statements or must otherwise have been disambiguated at the call site via a namespace prefix (negating the need to do any searching at all).
So simple ctrl-f in the file would do (or the call site would identify it).
I've no idea what you're trying to say, but as far as I can interpret it when it comes to Rust you got things exactly backwards:
foo().bar().baz()
if everything is monomorphic, there is no requirement that the result of bar() be a member of a direct dependency, to say nothing of being imported into the local scope.
If `baz()` is a member of a trait, however, that trait must be in-scope.
I'm talking about a hypothetical other language without ad-hoc polymorphism (in the spirit of the original article comparing Rust against other languages such as e.g. Go) and also in this case without methods. One poster child for this kind of programming is Elm (there are several other even more niche languages that do this as well).
I'm... not sure what you'd want to happen when there are literally 5 methods called write_u16, how is a general-purpose search to know which one you're looking for without more information? If you want contextual matching... use an IDE (or hook rust-analyser into your editor of preference).
(also there are way more than 5 matches in total as there are methods like `write_u16_into` which would also match at a lower rank).