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.

Sign up for GitHub

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

Jump to bottom

Reconsider default-public struct fields #11809

Closed
brson opened this issue Jan 26, 2014 · 4 comments
Closed

Reconsider default-public struct fields #11809

brson opened this issue Jan 26, 2014 · 4 comments
Milestone
1.0

Comments

@brson
Copy link
Contributor

brson commented Jan 26, 2014

Not sure if there's an issue for this, but I continue to see pull requests to hide incorrectly-public struct fields. I realize this has been beaten to death, but I still feel this is the wrong default that will continue to bite us. Nominating.
@brson
Copy link
Contributor Author

brson commented Jan 26, 2014

When we close this we should add an explanation to the design faq (#4047) to cement it.

@sfackler
Copy link
Member

There's some discussion of this in #8122.

@pnkfelix
Copy link
Member

I'm still in favor of the pub: solution I proposed in a comment from #8122.

(I'm only talking about implementing it with respect to structs; further comments from others on #8122 discussed generalizing it to handle enum and struct tuples as well, but its not obvious to be whether such generalization is a good idea.)

@pnkfelix
Copy link
Member

Accepted for 1.0, P-backcompat-lang.

flip1995 pushed a commit to flip1995/rust that referenced this issue Nov 16, 2023
@bors
Auto merge of rust-lang#11809 - hrxi:pr_if_same_then_else_style, r=Al…
3ea5bcf 
…exendoo

Change `if_same_then_else` to be a `style` lint

CC rust-lang#3770

From rust-lang/rust-clippy#3770 (comment) (`@flip1995):`

> Oh I thought I replied to this: I definitely see now that having this
> as a correctness lint might be the wrong categorization. What we might
> want to do is to just allow this lint, if there are comments in the
> arm bodies. But a good first step would be to downgrade this lint to
> style or complexity. I would vote for style since merging two arms is
> not always less complex.

changelog: [`if_same_then_else`]: Change to be a `style` lint
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
1.0
Development

No branches or pull requests
3 participants
@brson @pnkfelix @sfackler