Actually we don’t. I too would not like an API string.write_to_file(file). This is based on the intuition that the receiver should be the more special type. There are more file types than there are string types. Similarly, what I would normally put as the receiver of a Rust method I’d also put as the first argument of a function in Haskell, or the first argument of a free function in Rust.
What I’m saying is not that “anything goes” wrt. receivers, or that method call syntax is not about context, it is!
What I’m saying that most free functions really are just methods.
Take for example:
If we had UMCS, then IMO it makes sense to have the free functions with the right receiver be listed at the bottom of the documentation of the receivers type. In general, I’d be satisfied with being able to click somewhere, get on a special place and find all the relevant functions.
You don’t need rustdoc as a search engine to find it; @MajorBreakfast was asking specifically about how to deal with rustdoc, and I gave one possible solution.
With respect to searching for code, I think searching starts with the module (especially for traits), since it corresponds to the file name, and one file may have many types and impls, not just one. I think the searching procedure for free functions would be similar; you start with the name of the function, go to a use statement, go to the module, find it there.
if you see:
use path::to:my::free_fun;
fn stuff() {
receiver.free_fun(args..);
}
I think it is quite clear where to go looking.
Besides, if you really want to find code fast, you use an IDE which provides “Go to definition”. It would work fine to resolve the free function and jump to it; No manual searching at all!
