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: Don't distinguish structs and tuple structs with only private fields #38101

Open
clarfonthey opened this issue Dec 1, 2016 · 10 comments
Assignees
Labels
C-feature-request Category: A feature request, i.e: not implemented / a PR. E-medium Call for participation: Medium difficulty. Experience needed to fix: Intermediate. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.

Comments

@clarfonthey
Copy link
Contributor

clarfonthey commented Dec 1, 2016

For example, AddrParseError shows up as pub struct AddrParseError(_); and Ipv4Addr shows up as pub struct Ipv4Addr { /* fields omitted */ }

I feel like all structs should show up as the latter form if all of the fields are private. It technically doesn't matter that the struct is a tuple struct if the fields are all private. It's not a huge deal but it's an inconsistency that looks off to me.

@bluss bluss added the T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. label Dec 1, 2016
@bluss
Copy link
Member

bluss commented Dec 1, 2016

Yes, it is time, because the relevant part of #35626 is stable in nightly.

@steveklabnik steveklabnik added T-dev-tools Relevant to the dev-tools subteam, which will review and decide on the PR/issue. and removed T-tools labels May 18, 2017
@Mark-Simulacrum Mark-Simulacrum added the C-feature-request Category: A feature request, i.e: not implemented / a PR. label Jul 26, 2017
@steveklabnik
Copy link
Member

Triage: this bug still reproduces

@ehuss ehuss removed the T-dev-tools Relevant to the dev-tools subteam, which will review and decide on the PR/issue. label Jan 18, 2022
@clarfonthey
Copy link
Contributor Author

This bug still reproduces, in case you were wondering.

@jsha
Copy link
Contributor

jsha commented Feb 8, 2022

/cc @camelid who might be interested because it's similar in nature to #92699.

@camelid
Copy link
Member

camelid commented Feb 9, 2022

Yeah, it's always bothered me that tuple structs with all private fields show how many fields they have, even though they're supposed to be fully private.

@camelid camelid self-assigned this Feb 9, 2022
@clarfonthey
Copy link
Contributor Author

Bonus points if you make it so that it has the struct-field syntax if there are a mix of private/public fields, e.g. Struct { 1: T, /* some fields hidden */ }

@camelid
Copy link
Member

camelid commented Feb 10, 2022

In that case, I think I might make it look like Struct(..., T, ...) or Struct(/* private fields */, T, /* private fields */). Preferences?

@clarfonthey
Copy link
Contributor Author

The main benefit of the struct-based syntax is that it's actually valid Rust syntax, but if you don't care about that, the latter also works. I don't believe that there's any tuple-based syntax that works like that.

@camelid
Copy link
Member

camelid commented Feb 11, 2022

The main benefit of the struct-based syntax is that it's actually valid Rust syntax, but if you don't care about that, the latter also works. I don't believe that there's any tuple-based syntax that works like that.

Struct { 1: T } doesn't seem to be valid syntax, unless you were referring to something else?

@camelid camelid changed the title docs: Don't distinguish structs and tuple structs with only private fields rustdoc: Don't distinguish structs and tuple structs with only private fields Feb 11, 2022
@clarfonthey
Copy link
Contributor Author

So, I should have clarified: Struct { 1: T } isn't a valid struct definition, but Struct { 1: x } is a valid pattern. So, I guess what I meant to say was that it's closer to valid Rust syntax, although it's still invalid.

@lolbinarycat lolbinarycat added the E-medium Call for participation: Medium difficulty. Experience needed to fix: Intermediate. label Nov 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-feature-request Category: A feature request, i.e: not implemented / a PR. E-medium Call for participation: Medium difficulty. Experience needed to fix: Intermediate. 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

8 participants