4 ms·

For me, the question in Rust is not, what's a reference. But how do I find all functions applicable to a given type? In C/C++, I can just grep the header file

For me, the question in Rust is not, what's a reference. But how do I find all functions applicable to a given type? In C/C++, I can just grep the header files for the type name and voilà. I find header-less languages like Rust or Swift really obscure in that way.

kibwen 9y ago
I'm a bit confused, can you be more specific as to what you're asking for? grepping for types works just as well for headerless languages as it does for C++, though "finding all functions applicable to a given type" can't be done via grep for either C++ or Rust given that generics exist.
crispweed 9y ago
I guess tooling can help here? It seems like this information is all collected together for the docs, for example. Look at the page for std::vec::Vec, for example (https://doc.rust-lang.org/std/vec/struct.Vec.html https://doc.rust-lang.org/std/vec/struct.Vec.html). Here, you have sections for: 'Methods', 'Methods from Deref<Target=[T]>' and 'Trait Implementations', and then it seems that if you look through all these sections, you can see everything that can be called on this type, highlighted in the same light brown colour. It would be quite nice to get an alphabetically ordered list of just these method names, also..
MaulingMonkey 9y ago
Header diving certainly works well for some C/C++ codebases, but not all I've sadly discovered. The rough analog in Rust might be grepping rustdoc generated documentation, which should at least generally tell you what exists / is publicly exposed. Grepping the full source with extra filters like \bfn\b or \bpub fun\b might be another option. Like C++, you can also (ab)use intellisense to find a lot of them as well. I should hack more on Visual Rust to improve the situation there...
pjmlp 9y ago
By making use of an IDE or tools like RLS.
simias 9y ago
Interesting, if there's one thing I really don't miss in Rust it's bloody headers. Can't you simply use the docs? When I code in Rust I generally have the docs opened: https://doc.rust-lang.org/std/vec/struct.Vec.html https://doc.rust-lang.org/std/vec/struct.Vec.html (or more like likely the locally installed version). Most crates have documentation available as well (generally linked directly from their entry on crates.io) and if it's not online for some reason you can just run "cargo doc" to generate it locally. Randomly taking the "image" crate as an example: https://docs.rs/image/0.17.0/image/ https://docs.rs/image/0.17.0/image/ Beats grepping header files IMO.
- jcelerier 9y ago
  > Beats grepping header files IMO. who greps header files in 2017 (or even 2010) ? just fuzzy search a few characters that more or less looks like what you want in your IDE's search box.
  - jstimpfle 9y ago
    I still grep header, as well as implementation, files a lot. I miss being able to fuzzy search sometimes, but I keep coming back to vim. IDEs just don't cut it for me. They are too slow (Visual Studio 2017 on my desktop from 2011 is unbearable for even starting a new project). And most things I really need to do - in vim they are a few memorized keypresses or a plain shell command in a Makefile away, while in IDEs I have to dig through wizards which really brings me out of the zone. Not relying on API search much has the huge advantage of not relying on external APIs, which leads to good modularization. As a general rule, a module shouldn't call into other modules much. And by the way it's the same for OOP: OOP has the advantage of supporting IDE member/method autocomplete (noun first syntax), but it's just the wrong mindset for me and leads to really broken architectures.
    - wasted_intel 9y ago
      > Not relying on API search much has the huge advantage of not relying on external APIs, which leads to good modularization. As a general rule, a module shouldn't call into other modules much. When writing Rust, you'll likely use the standard library a lot; this rule might not be as applicable as in other languages/environments.
Manishearth 9y ago
Generally most inherent methods are listed in the same file as the type. Trait implementations may bring in other methods and may be listed elsewhere, but C++ doesn't help with this either (C++ doesn't have traits but there are common patterns that provide similar functionality) Most folks use the autogenerated docs (cargo doc), which list all the methods. But also when reading code it's not hard to grep for impls.

kibwen 9y ago

I'm a bit confused, can you be more specific as to what you're asking for? grepping for types works just as well for headerless languages as it does for C++, though "finding all functions applicable to a given type" can't be done via grep for either C++ or Rust given that generics exist.

crispweed 9y ago

I guess tooling can help here? It seems like this information is all collected together for the docs, for example. Look at the page for std::vec::Vec, for example (https://doc.rust-lang.org/std/vec/struct.Vec.html https://doc.rust-lang.org/std/vec/struct.Vec.html). Here, you have sections for: 'Methods', 'Methods from Deref<Target=[T]>' and 'Trait Implementations', and then it seems that if you look through all these sections, you can see everything that can be called on this type, highlighted in the same light brown colour. It would be quite nice to get an alphabetically ordered list of just these method names, also..

MaulingMonkey 9y ago

Header diving certainly works well for some C/C++ codebases, but not all I've sadly discovered. The rough analog in Rust might be grepping rustdoc generated documentation, which should at least generally tell you what exists / is publicly exposed. Grepping the full source with extra filters like \bfn\b or \bpub fun\b might be another option. Like C++, you can also (ab)use intellisense to find a lot of them as well. I should hack more on Visual Rust to improve the situation there...

pjmlp 9y ago

By making use of an IDE or tools like RLS.

simias 9y ago

Interesting, if there's one thing I really don't miss in Rust it's bloody headers. Can't you simply use the docs? When I code in Rust I generally have the docs opened: https://doc.rust-lang.org/std/vec/struct.Vec.html https://doc.rust-lang.org/std/vec/struct.Vec.html (or more like likely the locally installed version). Most crates have documentation available as well (generally linked directly from their entry on crates.io) and if it's not online for some reason you can just run "cargo doc" to generate it locally. Randomly taking the "image" crate as an example: https://docs.rs/image/0.17.0/image/ https://docs.rs/image/0.17.0/image/ Beats grepping header files IMO.

jcelerier 9y ago
> Beats grepping header files IMO. who greps header files in 2017 (or even 2010) ? just fuzzy search a few characters that more or less looks like what you want in your IDE's search box.
- jstimpfle 9y ago
  I still grep header, as well as implementation, files a lot. I miss being able to fuzzy search sometimes, but I keep coming back to vim. IDEs just don't cut it for me. They are too slow (Visual Studio 2017 on my desktop from 2011 is unbearable for even starting a new project). And most things I really need to do - in vim they are a few memorized keypresses or a plain shell command in a Makefile away, while in IDEs I have to dig through wizards which really brings me out of the zone. Not relying on API search much has the huge advantage of not relying on external APIs, which leads to good modularization. As a general rule, a module shouldn't call into other modules much. And by the way it's the same for OOP: OOP has the advantage of supporting IDE member/method autocomplete (noun first syntax), but it's just the wrong mindset for me and leads to really broken architectures.
  - wasted_intel 9y ago
    > Not relying on API search much has the huge advantage of not relying on external APIs, which leads to good modularization. As a general rule, a module shouldn't call into other modules much. When writing Rust, you'll likely use the standard library a lot; this rule might not be as applicable as in other languages/environments.

Manishearth 9y ago

Generally most inherent methods are listed in the same file as the type. Trait implementations may bring in other methods and may be listed elsewhere, but C++ doesn't help with this either (C++ doesn't have traits but there are common patterns that provide similar functionality) Most folks use the autogenerated docs (cargo doc), which list all the methods. But also when reading code it's not hard to grep for impls.