Skip to content

rustdoc: separate trait docs from default impl docs? #139898

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

Closed
sgtatham opened this issue Apr 16, 2025 · 2 comments
Closed

rustdoc: separate trait docs from default impl docs? #139898

sgtatham opened this issue Apr 16, 2025 · 2 comments

Comments

@sgtatham
Copy link

The documentation for a trait and its methods often includes advice, suggestions, or a list of options for the developer implementing the trait. For example, the docs for PartialEq::ne() mention that implementors shouldn't override the default version of ne() without a good reason.

This is useful advice if I'm reading the PartialEq documentation itself, as a developer figuring out how to implement it on one of my own types. But if I'm reading the documentation for a type which has implemented PartialEq, say in somebody else's crate, and I see the same text saying "implementors shouldn't override this without a good reason", it's very out of place. Firstly, it's directing the advice at the wrong person: I'm not in control of whether the crate author overrode ne(). And secondly, it's complaining about a thing that didn't even happen – very likely the reason that default method documentation is being shown to me is because the crate author sensibly didn't override the default ne().

It would be useful if there was a way to separate the "advice to implementors" part of the trait documentation from the text about what each trait method does. That way, in the context of an existing implementation of the trait, this kind of out-of-place text wouldn't appear at all.

(Original version of this thought on Mastodon, although there it forms a combined rant with a separate complaint that implementors often don't override the default docs, e.g. saying which implementation choice they did make out of the options, or explaining what addition semantically means for their type. Here I'm only discussing point 2 of the combined complaint. In the Mastodon thread @GuillaumeGomez suggested I raise this ticket for discussion.)

@rustbot rustbot added the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label Apr 16, 2025
@llogiq
Copy link
Contributor

llogiq commented Apr 16, 2025

Duplicate of #139855.

@GuillaumeGomez
Copy link
Member

Closing since it's a duplicate but thanks for opening the issue in any case. :)

@jieyouxu jieyouxu removed the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label Apr 17, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants