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

Add an intra-doc link disambiguator for fields #80283

Open
camelid opened this issue Dec 22, 2020 · 8 comments · May be fixed by #130587
Open

Add an intra-doc link disambiguator for fields #80283

camelid opened this issue Dec 22, 2020 · 8 comments · May be fixed by #130587
Assignees
Labels
A-intra-doc-links Area: Intra-doc links, the ability to link to items in docs by name C-feature-request Category: A feature request, i.e: not implemented / a PR. needs-fcp This change is insta-stable, so needs a completed FCP to proceed. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.

Comments

@camelid
Copy link
Member

camelid commented Dec 22, 2020

I have code like this:

struct Foo { bar: i32 }

impl Foo {
    /// Get a reference to [`Foo::bar`].
    //                            ^^^ I want this to link to the field. Currently it links to the method.
    fn bar(&self) -> i32 { self.bar }
}

This is a decently-common Rust "design pattern" where you have have a private
field but give public read-only access via a method of the same name. However,
there's no way in rustdoc currently to disambiguate between the function and the
field. Rustdoc seems to always link to the method in this case.

It would be good if we had a disambiguator for struct/enum fields: something
like field@Foo::bar. I don't think it's necessary to have a different one for
struct vs enum variant fields, but we should still decide that since intra-doc
links are now stable (and thus we can't remove things).

See the discussion on Zulip.

cc @jyn514

@camelid camelid added A-intra-doc-links Area: Intra-doc links, the ability to link to items in docs by name C-feature-request Category: A feature request, i.e: not implemented / a PR. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. labels Dec 22, 2020
@camelid camelid changed the title Add a disambiguator for fields Add an intra-doc link disambiguator for fields Dec 22, 2020
@camelid camelid added the needs-fcp This change is insta-stable, so needs a completed FCP to proceed. label Dec 22, 2020
@camelid
Copy link
Member Author

camelid commented Dec 23, 2020

It would be nice if we had special-casing for the disambiguator so that [`field@Foo::bar`] renders as Foo.bar. That would save a lot of doing [`Foo.bar`][field@Foo::bar].

@camelid camelid self-assigned this Mar 26, 2021
@camelid camelid added needs-fcp This change is insta-stable, so needs a completed FCP to proceed. and removed needs-fcp This change is insta-stable, so needs a completed FCP to proceed. labels Mar 26, 2021
@GoldsteinE
Copy link
Contributor

IMHO using [`Foo.bar`] to create a link to the field is much more intuitive than [`Foo.bar`][field@Foo::bar] and generally looks nicer. Fields can’t even be referred with ::, so it’s hard to guess this syntax.

@JarredAllen
Copy link
Contributor

JarredAllen commented Jun 1, 2023

IMHO using [`Foo.bar`] to create a link to the field is much more intuitive than [`Foo.bar`][field@Foo::bar] and generally looks nicer. Fields can’t even be referred with ::, so it’s hard to guess this syntax.

Yeah, I second this. [`Foo::bar`] for unambiguous cases needs to stick around for backwards-compatibility, but I think [`Foo.bar`] is a better disambiguator for fields than [`field@Foo::bar`]. It matches the syntax used to access it better, and also imo it fits cleaner into the pattern of [`Foo::bar()`] and [`Foo::bar!`] disambiguators for methods and macros.

@GoldsteinE
Copy link
Contributor

I think I’m willing to contribute this if the idea itself gets accepted. I kinda don’t have the energy to push it, ping relevant people, write justifications and do other social stuff like that right now. I’m not even sure how to make (organisational) progress here, since this issue exists for 3 years and there’s no reaction from the rustdoc team.

@jyn514
Copy link
Member

jyn514 commented Jun 1, 2023

You are talking about a different problem than the one mentioned in the issue. We are not planning to add . to the intra doc link syntax for the reasons mentioned in #75437.

@GoldsteinE
Copy link
Contributor

That’s kinda sad but fair. How about special-casing [`field@Foo::bar`] to render as Foo.bar that @camelid wrote about?

@jyn514
Copy link
Member

jyn514 commented Jun 1, 2023

That should probably have an FCP from the rustdoc team. You can bring it up on Zulip if you want to get initial feedback on whether they think it's a good idea: https://rust-lang.zulipchat.com/#narrow/stream/266220-rustdoc

@gondolyr
Copy link

gondolyr commented Aug 5, 2024

For anyone that is still looking for a way to link to a struct field, adding #structfield.<FIELDNAME> at the end of the link seems to work as a workaround, where <FIELDNAME> is the struct field you wish to link to (without the angle brackets).

This appears to generate the following URL when I generate the docs with rustdoc: file:///home/myuser/my_project/target/doc/my_sub_module/struct.Foo.html#structfield.bar

Example:

struct Foo {
    bar: i32,
}

impl Foo {
    // THE LINE BELOW ⬇️
    /// Get a reference to [`crate::my_sub_module::Foo#structfield.bar`].
    fn bar(&self) -> i32 {
        self.bar
    }
}

@jyn514 jyn514 linked a pull request Sep 19, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-intra-doc-links Area: Intra-doc links, the ability to link to items in docs by name C-feature-request Category: A feature request, i.e: not implemented / a PR. needs-fcp This change is insta-stable, so needs a completed FCP to proceed. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.
Projects
None yet
6 participants