You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For modules, the URLs generated by rustdoc correlate correctly with the module structure, but the same is not true for types. It would be better if, instead of generating std/collections/struct.HashMap.html, rustdoc generated std/collections/HashMap. This would enable anyone who knows the website at which the documentation for their library is stored and the namespace object they wish to look up to navigate to this page with ease. Similarly, methods should probably drop the method. prefix, and be found such as std/collections/HashMap#contains_key.
The .html affix conveys no useful information at all, and the struct. prefix conveys information which is not helpful for disambiguating this page from other pages in the documentation hierarchy.
The exception to this seems to be the strange std/primitive.char.html pages. I don't exactly know how these are generated, and they are difficult to locate already in the documentation generated by rustdoc; at very least these should be at std/primitive.char, without the .html.
If this change is considered valuable, it seems somewhat high priority to limit the number of links that will exist to current page schemes as Rust continues to gain momentum post-1.0
As an addendum, I want to say that rustdoc is the best doc system of any language I've used and an incredible, bountiful asset to Rust.
The text was updated successfully, but these errors were encountered:
Note rustdoc is intentionally designed to generate a number of standalone files which can be served as a static site, so it's not always possible to have complete control over the URL. That being said, I'm sure we could improve on this!
The prime reason for struct. or fn. prefixes is that Rust has two distinct namespaces. For example:
pubfnfoo(){}pubtypefoo = usize;
...would give two pages fn.foo.html and type.foo.html with distinct contents. It might still be possible to have a disambiguation page named foo.html which can be a simple redirect when there is no ambiguity. I'm less sure about another option, namely, to redirect <shortty>.foo.html to foo.html, but it will still work if the external crate always links to the full (but possibly non-canonical) URL.
We have redirects using namespaces rather than the annoying struct/fn stuff, but the general opinion was that we can basically never change Rustdoc URLs because people might link them (which I'm still a bit salty about, but meh). So, probably fine to close this because it doesn't seem actionable.
For modules, the URLs generated by rustdoc correlate correctly with the module structure, but the same is not true for types. It would be better if, instead of generating
std/collections/struct.HashMap.html
, rustdoc generatedstd/collections/HashMap
. This would enable anyone who knows the website at which the documentation for their library is stored and the namespace object they wish to look up to navigate to this page with ease. Similarly, methods should probably drop themethod.
prefix, and be found such asstd/collections/HashMap#contains_key
.The
.html
affix conveys no useful information at all, and thestruct.
prefix conveys information which is not helpful for disambiguating this page from other pages in the documentation hierarchy.The exception to this seems to be the strange
std/primitive.char.html
pages. I don't exactly know how these are generated, and they are difficult to locate already in the documentation generated by rustdoc; at very least these should be atstd/primitive.char
, without the.html
.If this change is considered valuable, it seems somewhat high priority to limit the number of links that will exist to current page schemes as Rust continues to gain momentum post-1.0
As an addendum, I want to say that rustdoc is the best doc system of any language I've used and an incredible, bountiful asset to Rust.
The text was updated successfully, but these errors were encountered: