@@ -8,11 +8,13 @@ This is a conventions RFC for settling a number of remaining naming conventions:
88
99* Referring to types in method names
1010* Iterator type names
11+ * Additional iterator method names
1112* Getter/setter APIs
1213* Associated types
1314* Trait naming
1415* Lint naming
1516* Suffix ordering
17+ * Prelude traits
1618
1719It also proposes to standardize on lower case error messages within the compiler
1820and standard library.
@@ -125,6 +127,35 @@ Disadvantages:
125127 conventions. In most cases, this situation should be taken as an indication
126128 that a more refined module hierarchy is called for.
127129
130+ ## Additional iterator method names
131+
132+ An [ earlier RFC] ( https://github.com/rust-lang/rfcs/pull/199 ) settled the
133+ conventions for the "standard" iterator methods: ` iter ` , ` iter_mut ` ,
134+ ` into_iter ` .
135+
136+ However, there are many cases where you also want "nonstandard" iterator
137+ methods: ` bytes ` and ` chars ` for strings, ` keys ` and ` values ` for maps,
138+ the various adapters for iterators.
139+
140+ This RFC proposes the following convention:
141+
142+ * Use ` iter ` (and variants) for data types that can be viewed as containers,
143+ and where the iterator provides the "obvious" sequence of contained items.
144+
145+ * If there is no single "obvious" sequence of contained items, or if there are
146+ multiple desired views on the container, provide separate methods for these
147+ that do * not* use ` iter ` in their name. The name should instead directly
148+ reflect the view/item type being iterated (like ` bytes ` ).
149+
150+ * Likewise, for iterator adapters (` filter ` , ` map ` and so on) or other
151+ iterator-producing operations (` intersection ` ), use the clearest name to
152+ describe the adapter/operation directly, and do not mention ` iter ` .
153+
154+ * If not otherwise qualified, an iterator-producing method should provide an
155+ iterator over immutable references. Use the ` _mut ` suffix for variants
156+ producing mutable references, and the ` into_ ` prefix for variants consuming
157+ the data in order to produce owned values.
158+
128159## Getter/setter APIs
129160
130161Some data structures do not wish to provide direct access to their fields, but
@@ -202,6 +233,29 @@ However, the *mut* suffix is so common, and is now entrenched as showing up in
202233final position, that this RFC does propose one simple rule: if there are
203234multiple suffixes including ` mut ` , place ` mut ` last.
204235
236+ ## Prelude traits
237+
238+ It is not currently possible to define inherent methods directly on basic data
239+ types like ` char ` or slices. Consequently, ` libcore ` and other basic crates
240+ provide one-off traits (like ` ImmutableSlice ` or ` Char ` ) that are intended to be
241+ implemented solely by these primitive types, and which are included in the
242+ prelude.
243+
244+ These traits are generally * not* designed to be used for generic programming,
245+ but the fact that they appear in core libraries with such basic names makes it
246+ easy to draw the wrong conclusion.
247+
248+ This RFC proposes to use a ` Prelude ` suffix for these basic traits. Since the
249+ traits are, in fact, included in the prelude their names do not generally appear
250+ in Rust programs. Therefore, choosing a longer and clearer name will help avoid
251+ confusion about the intent of these traits, and will avoid namespace polution.
252+
253+ (There is one important drawback in today's Rust: associated functions in these
254+ traits cannot yet be called directly on the types implementing the traits. These
255+ functions are the one case where you would need to mention the trait by name,
256+ today. Hopefully, this situation will change before 1.0; otherwise we may need a
257+ separate plan for dealing with associated functions.)
258+
205259## Error messages
206260
207261Error messages -- including those produced by ` fail! ` and those placed in the
0 commit comments