# guidelines

**URL:** https://internals.rust-lang.org/c/guidelines/8.md

[Latest](https://internals.rust-lang.org/latest.md) · [Categories](https://internals.rust-lang.org/categories.md)

---

## [About the guidelines category](https://internals.rust-lang.org/t/about-the-guidelines-category/40)

<div class="topic-metadata">

**Author:** [@cmr](https://internals.rust-lang.org/u/cmr)\
**Replies:** 1\
**Last updated:** [July 11, 2014, 12:25am UTC](https://internals.rust-lang.org/t/about-the-guidelines-category/40 "2014-07-11T00:25:26Z")

</div>

Discussion about the Rust Guidelines. Available rendered here and as source. Use the "style" subcategory as appropriate!

---

## [AI skills based on official guidelines](https://internals.rust-lang.org/t/ai-skills-based-on-official-guidelines/24566)

<div class="topic-metadata">

**Author:** [@MusicalNinjaDad](https://internals.rust-lang.org/u/MusicalNinjaDad)\
**Replies:** 22\
**Last updated:** [October 11, 2026, 4:43am UTC](https://internals.rust-lang.org/t/ai-skills-based-on-official-guidelines/24566 "2026-10-11T04:43:36Z")

</div>

One of rust's (many) outstanding features as a language is the quality of the documentation. Not just the library docs, the books, the reference but also the various guidelines. While much can be deterministically check…

---

## [No need for pub(crate) in binary crates?](https://internals.rust-lang.org/t/no-need-for-pub-crate-in-binary-crates/23607)

<div class="topic-metadata">

**Author:** [@krobelus](https://internals.rust-lang.org/u/krobelus)\
**Replies:** 5\
**Last updated:** [October 9, 2025, 7:17pm UTC](https://internals.rust-lang.org/t/no-need-for-pub-crate-in-binary-crates/23607 "2025-10-09T19:17:49Z")

</div>

In a crate with multiple binaries, I guess the benefits of using pub(crate) over pub are: the binary entrypoint modules cannot use the pub(crate) ones potentially fewer symbols in target/debug/libmycrate.rlib (but I co…

---

## [\[RE-POST\] Project guideline standard](https://internals.rust-lang.org/t/re-post-project-guideline-standard/14815)

<div class="topic-metadata">

**Author:** [@Azgrom](https://internals.rust-lang.org/u/Azgrom)\
**Replies:** 0\
**Last updated:** [June 2, 2021, 6:46pm UTC](https://internals.rust-lang.org/t/re-post-project-guideline-standard/14815 "2021-06-02T18:46:47Z")

</div>

This is a re-posted topic from the users forum that got no engagement (maybe for being an irrelevant topic or for being seeing by the correct target public). Since there is the possibility of it to create an useful discu…

---

## [How to properly move ownership in an inner loop in Rust?](https://internals.rust-lang.org/t/how-to-properly-move-ownership-in-an-inner-loop-in-rust/14696)

<div class="topic-metadata">

**Author:** [@An7One](https://internals.rust-lang.org/u/An7One)\
**Replies:** 1\
**Last updated:** [May 13, 2021, 8:17am UTC](https://internals.rust-lang.org/t/how-to-properly-move-ownership-in-an-inner-loop-in-rust/14696 "2021-05-13T08:17:39Z")

</div>

How to properly move ownership of the data, in an inner loop, so that once the final iteration gets done, the container iterated will be Drop() ed. For example: let left\_strs: Vec\<String\> = Self::allowed(&slice\[..i\]); …

---

## [Style guide for comments](https://internals.rust-lang.org/t/style-guide-for-comments/8995)

<div class="topic-metadata">

**Author:** [@alexreg](https://internals.rust-lang.org/u/alexreg)\
**Replies:** 30\
**Last updated:** [December 28, 2018, 5:00pm UTC](https://internals.rust-lang.org/t/style-guide-for-comments/8995 "2018-12-28T17:00:26Z")

</div>

The topic of stylistic decisions in the source code for rustc recently arose after a a large PR of cosmetic and other minor changes that I made. Although I argue I made a lot of the comments more readable and consistentl…

---

## [When should I use #\[inline\]?](https://internals.rust-lang.org/t/when-should-i-use-inline/598)

<div class="topic-metadata">

**Author:** [@SimonSapin](https://internals.rust-lang.org/u/SimonSapin)\
**Replies:** 9\
**Last updated:** [June 21, 2017, 11:41am UTC](https://internals.rust-lang.org/t/when-should-i-use-inline/598 "2017-06-21T11:41:42Z")

</div>

Inline attributes can be added to functions and methods. As a library author, when should I use them? I feel like the compile probably knows better than me when inlining is beneficial or not, so I don’t use #\[inline(al…

---

## [Requirements for Rust](https://internals.rust-lang.org/t/requirements-for-rust/2781)

<div class="topic-metadata">

**Author:** [@martalopes](https://internals.rust-lang.org/u/martalopes)\
**Replies:** 3\
**Last updated:** [October 14, 2015, 12:22pm UTC](https://internals.rust-lang.org/t/requirements-for-rust/2781 "2015-10-14T12:22:56Z")

</div>

Hello! I would like to know which are the requirements for contributing to Rust. I'm not talking about the code standards because I know that's available on documentation. Instead I would like to know which are the 'prob…

---

## [Working around back-compat issues with unsafe?](https://internals.rust-lang.org/t/working-around-back-compat-issues-with-unsafe/2346)

<div class="topic-metadata">

**Author:** [@aidancully](https://internals.rust-lang.org/u/aidancully)\
**Replies:** 8\
**Last updated:** [July 12, 2015, 4:49pm UTC](https://internals.rust-lang.org/t/working-around-back-compat-issues-with-unsafe/2346 "2015-07-12T16:49:14Z")

</div>

With a heavy heart, I've included a section in an RFC I submitted that asks to expand the definition of "unsafe" to allow marking code as "unsafe" to avoid backwards-compatibility hazards when safe code changes. The RFC …

---

## [Should setters mutate, move, or clone the value?](https://internals.rust-lang.org/t/should-setters-mutate-move-or-clone-the-value/1092)

<div class="topic-metadata">

**Author:** [@theemathas](https://internals.rust-lang.org/u/theemathas)\
**Replies:** 12\
**Last updated:** [April 18, 2015, 5:51am UTC](https://internals.rust-lang.org/t/should-setters-mutate-move-or-clone-the-value/1092 "2015-04-18T05:51:50Z")

</div>

The guideline (which claims to be approved by RFC #344) says that the setter should have the format set\_foo(&self, val: T) (or set\_foo(&self, val: &T), but I'd ignore this issue for the rest of this post). However, a met…

---

## [Are memory leaks considered to violate memory safety?](https://internals.rust-lang.org/t/are-memory-leaks-considered-to-violate-memory-safety/1674)

<div class="topic-metadata">

**Author:** [@theemathas](https://internals.rust-lang.org/u/theemathas)\
**Replies:** 11\
**Last updated:** [April 16, 2015, 3:32am UTC](https://internals.rust-lang.org/t/are-memory-leaks-considered-to-violate-memory-safety/1674 "2015-04-16T03:32:57Z")

</div>

According to the reference, "Leaks due to reference count cycles, even in the global heap" is not unsafe. However, that doesn't say anything about other types of memory leaks. Should memory leaks due to other problems …

---

## [What is backwards compatibility?](https://internals.rust-lang.org/t/what-is-backwards-compatibility/1780)

<div class="topic-metadata">

**Author:** [@theemathas](https://internals.rust-lang.org/u/theemathas)\
**Replies:** 6\
**Last updated:** [April 1, 2015, 10:20am UTC](https://internals.rust-lang.org/t/what-is-backwards-compatibility/1780 "2015-04-01T10:20:33Z")

</div>

In some cases, it is easy to see that a change is backwards compatible. However, many changes that seem backwards compatible are not. On the other hand, some kinds of changes rarely break code. We have to decide whethe…

---

## [Use of ref, must, & in let statements](https://internals.rust-lang.org/t/use-of-ref-must-in-let-statements/1466)

<div class="topic-metadata">

**Author:** [@arienmalec](https://internals.rust-lang.org/u/arienmalec)\
**Replies:** 0\
**Last updated:** [January 27, 2015, 9:52pm UTC](https://internals.rust-lang.org/t/use-of-ref-must-in-let-statements/1466 "2015-01-27T21:52:11Z")

</div>

See this Reddit thread: http://www.reddit.com/r/rust/comments/2tq33x/ref\_keyword/ let a = &y; let b = &mut y; let mut c = &y; let mut d = &mut y; Are semantically equivalent to: let ref a = y; let ref mut b = y; // …

---

## [Macro hygiene and the guides](https://internals.rust-lang.org/t/macro-hygiene-and-the-guides/1207)

<div class="topic-metadata">

**Author:** [@d3zd3z](https://internals.rust-lang.org/u/d3zd3z)\
**Replies:** 1\
**Last updated:** [January 6, 2015, 9:12pm UTC](https://internals.rust-lang.org/t/macro-hygiene-and-the-guides/1207 "2015-01-06T21:12:49Z")

</div>

According to http://doc.rust-lang.org/guide-macros.html#hygiene, macros have hygiene, but https://github.com/rust-lang/rust/issues/19700 indicates that they are only hygienic for let names. I'm guessing fixing this wil…

---

## [Multiple Line \`fn\` and \`impl\` Declarations](https://internals.rust-lang.org/t/multiple-line-fn-and-impl-declarations/1106)

<div class="topic-metadata">

**Author:** [@strega-nil](https://internals.rust-lang.org/u/strega-nil)\
**Replies:** 1\
**Last updated:** [December 29, 2014, 12:07am UTC](https://internals.rust-lang.org/t/multiple-line-fn-and-impl-declarations/1106 "2014-12-29T00:07:32Z")

</div>

So I'm looking at the rust style guide, and something came off as weird to me. In whitespace, it says that a multiple line function definition is written as: fn frobnicate(a: Bar, b: Bar, c: Bar, d: Bar) …

---

## [Trailing Commas in Matches, Structs, &c](https://internals.rust-lang.org/t/trailing-commas-in-matches-structs-c/683)

<div class="topic-metadata">

**Author:** [@strega-nil](https://internals.rust-lang.org/u/strega-nil)\
**Replies:** 10\
**Last updated:** [October 28, 2014, 10:08am UTC](https://internals.rust-lang.org/t/trailing-commas-in-matches-structs-c/683 "2014-10-28T10:08:13Z")

</div>

Here we have an open style question, on whether trailing commas in such a statement as this: Foo { bar: T, baz: T, } should be the default. I, personally, find this ugly in comparison to Foo { bar: T, …

---

## [Function argument/parameter indentation](https://internals.rust-lang.org/t/function-argument-parameter-indentation/50)

<div class="topic-metadata">

**Author:** [@doy](https://internals.rust-lang.org/u/doy)\
**Replies:** 48\
**Last updated:** [October 23, 2014, 10:17am UTC](https://internals.rust-lang.org/t/function-argument-parameter-indentation/50 "2014-10-23T10:17:20Z")

</div>

From the style guide: For multiline function signatures, each new line should align with the first parameter. Multiple parameters per line are permitted: fn frobnicate(a: Bar, b: Bar, c: Bar, d: Bar) …

---

## [Settling some key naming conventions](https://internals.rust-lang.org/t/settling-some-key-naming-conventions/269)

<div class="topic-metadata">

**Author:** [@aturon](https://internals.rust-lang.org/u/aturon)\
**Replies:** 58\
**Last updated:** [October 20, 2014, 7:10pm UTC](https://internals.rust-lang.org/t/settling-some-key-naming-conventions/269 "2014-10-20T19:10:33Z")

</div>

There are several important naming conventions that still need to be formally settled: prefix mut\_ versus suffix \_mut (https://github.com/rust-lang/rust/issues/13660) mut versus mut\_ref (https://github.com/rust-lang/…

---

## [A space after colons in macros](https://internals.rust-lang.org/t/a-space-after-colons-in-macros/348)

<div class="topic-metadata">

**Author:** [@sanxiyn](https://internals.rust-lang.org/u/sanxiyn)\
**Replies:** 5\
**Last updated:** [August 9, 2014, 3:25pm UTC](https://internals.rust-lang.org/t/a-space-after-colons-in-macros/348 "2014-08-09T15:25:30Z")

</div>

I note that while style guide says "Use a space after colons", almost no existing codes does so in macros. For example, macro\_rules! try( ($e:expr) =\> (match $e { Ok(e) =\> e, Err(e) =\> return Err(e) }) ) That is, $…

---

## [Type alignment in struct definitions](https://internals.rust-lang.org/t/type-alignment-in-struct-definitions/243)

<div class="topic-metadata">

**Author:** [@gsingh93](https://internals.rust-lang.org/u/gsingh93)\
**Replies:** 4\
**Last updated:** [July 23, 2014, 3:18pm UTC](https://internals.rust-lang.org/t/type-alignment-in-struct-definitions/243 "2014-07-23T15:18:40Z")

</div>

What do people think about aligning types in structs? An example, struct Foo { ab: u32, abcd: u32, a: u32 } As opposed to struct Foo { ab: u32, abcd: u32, a: u32 } Should this be encou…

---

## [Open brace placement: always on the same line?](https://internals.rust-lang.org/t/open-brace-placement-always-on-the-same-line/142)

<div class="topic-metadata">

**Author:** [@aturon](https://internals.rust-lang.org/u/aturon)\
**Replies:** 23\
**Last updated:** [July 22, 2014, 8:44pm UTC](https://internals.rust-lang.org/t/open-brace-placement-always-on-the-same-line/142 "2014-07-22T20:44:59Z")

</div>

Cross-referencing https://github.com/rust-lang/rust-guidelines/issues/19, which argues that having opening braces on their own line can sometimes be a readability win.

---

## [Space between procedure name and param list in declaration](https://internals.rust-lang.org/t/space-between-procedure-name-and-param-list-in-declaration/177)

<div class="topic-metadata">

**Author:** [@Almale](https://internals.rust-lang.org/u/Almale)\
**Replies:** 6\
**Last updated:** [July 21, 2014, 11:34pm UTC](https://internals.rust-lang.org/t/space-between-procedure-name-and-param-list-in-declaration/177 "2014-07-21T23:34:13Z")

</div>

I suggest to modify the style guide with putting a space between the procedure name and its parameter-list. Only in the declaration. My reasons: A space visually separates the function name, which is important, becas…

---

## [99 vs 100 column limit](https://internals.rust-lang.org/t/99-vs-100-column-limit/47)

<div class="topic-metadata">

**Author:** [@cmr](https://internals.rust-lang.org/u/cmr)\
**Replies:** 11\
**Last updated:** [July 18, 2014, 1:00am UTC](https://internals.rust-lang.org/t/99-vs-100-column-limit/47 "2014-07-18T01:00:54Z")

</div>

Continuing the discussion from Column limits and rightward drift: Nobody uses 100-column terminals anyway, and if we want to support that, shouldn't we also remove a few columns to allow space for a line number, for ex…

---

## [Don't indent inline modules](https://internals.rust-lang.org/t/dont-indent-inline-modules/94)

<div class="topic-metadata">

**Author:** [@superlukas](https://internals.rust-lang.org/u/superlukas)\
**Replies:** 8\
**Last updated:** [July 17, 2014, 10:39am UTC](https://internals.rust-lang.org/t/dont-indent-inline-modules/94 "2014-07-17T10:39:12Z")

</div>

This is the C++ style I (and most others?) use: namespace foo { namespace bar { void baz(); }} // namespace foo::bar The equivalent in Rust would be: pub mod foo { pub fn bar() { /\* ... \*/ } } // mod foo This i…

---

## [Column limits and rightward drift](https://internals.rust-lang.org/t/column-limits-and-rightward-drift/44)

<div class="topic-metadata">

**Author:** [@cmr](https://internals.rust-lang.org/u/cmr)\
**Replies:** 21\
**Last updated:** [July 17, 2014, 6:11am UTC](https://internals.rust-lang.org/t/column-limits-and-rightward-drift/44 "2014-07-17T06:11:28Z")

</div>

Lines must not exceed 99 characters. Why 99, and not 100, or some other arbitrary number? Use 4 spaces for indentation, not tabs. These two rules combined with pattern matching conspire to make me squeeze a lot of…

---

## [Using traits to share implementations](https://internals.rust-lang.org/t/using-traits-to-share-implementations/182)

<div class="topic-metadata">

**Author:** [@nathantypanski](https://internals.rust-lang.org/u/nathantypanski)\
**Replies:** 0\
**Last updated:** [July 16, 2014, 8:09pm UTC](https://internals.rust-lang.org/t/using-traits-to-share-implementations/182 "2014-07-16T20:09:35Z")

</div>

Currently we have this (blob reference, master is here) which contains an example of trait use to share implementations. trait Printable { // Default method implementation fn print(&self) { println!("{:?}", \*…
