-
Notifications
You must be signed in to change notification settings - Fork 13.6k
Open
Labels
C-feature-requestCategory: A feature request, i.e: not implemented / a PR.Category: A feature request, i.e: not implemented / a PR.E-mediumCall for participation: Medium difficulty. Experience needed to fix: Intermediate.Call for participation: Medium difficulty. Experience needed to fix: Intermediate.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.
Description
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.
Rufflewind and Scripter17
Metadata
Metadata
Assignees
Labels
C-feature-requestCategory: A feature request, i.e: not implemented / a PR.Category: A feature request, i.e: not implemented / a PR.E-mediumCall for participation: Medium difficulty. Experience needed to fix: Intermediate.Call for participation: Medium difficulty. Experience needed to fix: Intermediate.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.
Type
Projects
Milestone
Relationships
Development
Select code repository
Activity
bluss commentedon Dec 1, 2016
Yes, it is time, because the relevant part of #35626 is stable in nightly.
steveklabnik commentedon Jan 9, 2020
Triage: this bug still reproduces
clarfonthey commentedon Feb 7, 2022
This bug still reproduces, in case you were wondering.
jsha commentedon Feb 8, 2022
/cc @camelid who might be interested because it's similar in nature to #92699.
camelid commentedon 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.
clarfonthey commentedon Feb 9, 2022
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 commentedon Feb 10, 2022
In that case, I think I might make it look like
Struct(..., T, ...)
orStruct(/* private fields */, T, /* private fields */)
. Preferences?clarfonthey commentedon 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.
camelid commentedon Feb 11, 2022
Struct { 1: T }
doesn't seem to be valid syntax, unless you were referring to something else?[-]docs: Don't distinguish structs and tuple structs with only private fields[/-][+]rustdoc: Don't distinguish structs and tuple structs with only private fields[/+]clarfonthey commentedon Feb 11, 2022
So, I should have clarified:
Struct { 1: T }
isn't a valid struct definition, butStruct { 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.