-
-
Notifications
You must be signed in to change notification settings - Fork 14.9k
rustdoc support for per-parameter documentation #57525
Copy link
Copy link
Open
Labels
A-attributesArea: Attributes (`#[…]`, `#![…]`)Area: Attributes (`#[…]`, `#![…]`)C-feature-requestCategory: A feature request, i.e: not implemented / a PR.Category: A feature request, i.e: not implemented / a PR.T-rustdocRelevant to the rustdoc team, which will review and decide on the PR/issue.Relevant to the rustdoc team, which will review and decide on the PR/issue.needs-rfcThis change is large or controversial enough that it should have an RFC accepted before doing it.This change is large or controversial enough that it should have an RFC accepted before doing it.
Metadata
Metadata
Assignees
Labels
A-attributesArea: Attributes (`#[…]`, `#![…]`)Area: Attributes (`#[…]`, `#![…]`)C-feature-requestCategory: A feature request, i.e: not implemented / a PR.Category: A feature request, i.e: not implemented / a PR.T-rustdocRelevant to the rustdoc team, which will review and decide on the PR/issue.Relevant to the rustdoc team, which will review and decide on the PR/issue.needs-rfcThis change is large or controversial enough that it should have an RFC accepted before doing it.This change is large or controversial enough that it should have an RFC accepted before doing it.
Type
Fields
Give feedbackNo fields configured for issues without a type.
It appears to me that this pattern of documenting function parameter has become an informal standard:
It's quite sub-optimal currently for a number of reasons:
So not only it's not exactly most convenient, it's also easy to get the docs de-synchronized from the code (notice the
document_idabove ^). It would be much better if we could do this instead:Does that sound remotely possible? With an assumption that the latter case would produce near-identical documentation to the former.