Skip to content

docs for Traits get duplicated because of different types #24558

Open
@mdinger

Description

@mdinger

f32 for example essentially supports traits like Add which have multiple copies which aren't duplicates but seem repetitive because they are essentially very similar:

Currently:

impl Add<f32> for f32
    type Output = f32

    fn add(self, other: f32) -> f32

impl<'a> Add<f32> for &'a f32
    type Output = f32::Output

    fn add(self, other: f32) -> f32::Output

impl<'a> Add<&'a f32> for f32
    type Output = f32::Output

    fn add(self, other: &'a f32) -> f32::Output

impl<'a, 'b> Add<&'a f32> for &'b f32
    type Output = f32::Output

    fn add(self, other: &'a f32) -> f32::Output

It would be very nice if these could be combined so the repetition is less drastic. I've only come up with 2 options so far but maybe there are more.

Option A:

This is tricky to improve because all are different. One course would be to collapse all but the last by default which would make it look like the following block. This would also aid #21660 . This makes all the types clear but only shows one method because all the methods will be the same.

+impl Add<f32> for f32
+impl<'a> Add<f32> for &'a f32
+impl<'a> Add<&'a f32> for f32
-impl<'a, 'b> Add<&'a f32> for &'b f32
    type Output = f32::Output

    fn add(self, other: &'a f32) -> f32::Output

Option B:

Use some type of shorthand to include all options (like globbing). This should expand to specifics if desired I suppose.

impl<.*> Add<.* f32> for .* f32
    type Output = f32.*

    fn add(self, other: .* f32) -> f32::Output

Option A looks the most practical. I'm trying to think of a better way to include only one but still allow the specifics to be examined but haven't come up with any better ideas.

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-rustdoc-uiArea: Rustdoc UI (generated HTML)A-trait-systemArea: Trait systemC-feature-requestCategory: A feature request, i.e: not implemented / a PR.E-needs-designThis issue needs exploration and design to see how and if we can fix/implement itT-rustdocRelevant to the rustdoc team, which will review and decide on the PR/issue.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions