Skip to content
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

Rustdoc URLs should more precisely match internal structure #25226

Closed
withoutboats opened this issue May 8, 2015 · 4 comments
Closed

Rustdoc URLs should more precisely match internal structure #25226

withoutboats opened this issue May 8, 2015 · 4 comments
Labels
T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.

Comments

@withoutboats
Copy link
Contributor

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.

@alexcrichton alexcrichton added the T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. label May 9, 2015
@alexcrichton
Copy link
Member

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!

@lifthrasiir
Copy link
Contributor

The prime reason for struct. or fn. prefixes is that Rust has two distinct namespaces. For example:

pub fn foo() {}
pub type foo = 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.

@steveklabnik
Copy link
Member

Triage: I believe that @rust-lang/tools has wanted to move away from this, specifically so that tooling can more easily generate URLs.

@nrc
Copy link
Member

nrc commented Nov 15, 2016

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.

@nrc nrc closed this as completed Nov 15, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

5 participants