-
Notifications
You must be signed in to change notification settings - Fork 13k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
standardise whether detailed descriptions & examples of types go on the type or the module #14967
Comments
Other somewhat relevant modules:
|
My gut says "Full docs in the module, types should mention 'see module for full docs' |
cc me |
Steve's gut sounds right to me. Would especially work better if we had sane intra-links. |
Although doc'ing the type can be more "portable" in the face of re-exports. |
Hm, so I'm now starting to prefer the other direction. Module-level docs are great for telling an overall narrative for people who are exploring, but they are not good when people are looking up a type/method etc. I guess the ideal option would be "both"? But I'm not really sure. As @gankro says links could help... |
This chapter covers writing documentation in depth. Fixes rust-lang#4361 Fixes rust-lang#12862 Fixes rust-lang#14070 Fixes rust-lang#14967
…eykril Revert "Add mandatory panic contexts to all threadpool tasks" Reverts rust-lang/rust-analyzer#14965 This won't quite work actually given the use of `catch_unwind` in some of these
E.g.
Result
is very brief, referring to the modulestd::result
, which is very extensive, and even includes a redefinition of theResult
type!On the other hand
std::collections::hashmap
is short, whileHashMap
is more detailed (i'll note that these aren't precisely equivalent, sinceHashSet
is in that module too). Similarly,Vec
is longer thanstd::vec
.The text was updated successfully, but these errors were encountered: