-
Notifications
You must be signed in to change notification settings - Fork 13k
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
style-guide: Add language disclaiming any effects on non-default Rust styles #112944
style-guide: Add language disclaiming any effects on non-default Rust styles #112944
Conversation
… styles Make it clear that the style guide saying "must" doesn't forbid developers from doing differently (as though any power on this Earth could do that) and doesn't forbid tools from allowing any particular configuration options.
r? @yaahc (rustbot has picked a reviewer for you, use r? to override) |
Some changes occurred in src/doc/style-guide cc @rust-lang/style |
Seems good to me! I don't think people misinterpreting the guide as "forbidding" is a concern for people who actually want to flout the style guide per se. Rather, people may wish to adhere to the style guide on either part or all of its principles, and may want to better understand why it was written in a particular way, who it is addressing, and thus what "must" or "should" would "really mean" in context. I think this change at-a-glance seems to satisfy that, and probably any more significant revisions to the style guide that would clarify this further can happen later, in good time. |
@workingjubilee Yeah, I intend to follow up to this with further improvements to the language, so that people don't have to wonder what "should" means. |
@bors r+ rollup |
…vs-configurability, r=compiler-errors style-guide: Add language disclaiming any effects on non-default Rust styles Make it clear that the style guide saying "must" doesn't forbid developers from doing differently (as though any power on this Earth could do that) and doesn't forbid tools from allowing any particular configuration options. Otherwise, people might wonder (for instance) if there's a semantic difference between "must" and "should" in the style guide, and whether tools are "allowed" to offer configurability of something that says "must".
…iaskrgr Rollup of 9 pull requests Successful merges: - rust-lang#111747 (Don't structurally resolve during method ambiguity in probe) - rust-lang#112704 (slice::from_raw_parts: mention no-wrap-around condition) - rust-lang#112927 (Fix indentation for where clause in rustdoc pages) - rust-lang#112933 (Avoid `&format` in error message code) - rust-lang#112935 (style-guide: Fix typo) - rust-lang#112941 (typo) - rust-lang#112942 (style-guide: Organizational and editing tweaks (no semantic changes)) - rust-lang#112944 (style-guide: Add language disclaiming any effects on non-default Rust styles) - rust-lang#112948 (Avoid guessing unknown trait implementation in suggestions) r? `@ghost` `@rustbot` modify labels: rollup
Make it clear that the style guide saying "must" doesn't forbid
developers from doing differently (as though any power on this Earth
could do that) and doesn't forbid tools from allowing any particular
configuration options.
Otherwise, people might wonder (for instance) if there's a semantic difference
between "must" and "should" in the style guide, and whether tools are "allowed"
to offer configurability of something that says "must".