|
16 | 16 | //! This macro is implemented in the compiler to emit calls to this module in
|
17 | 17 | //! order to format arguments at runtime into strings and streams.
|
18 | 18 | //!
|
19 |
| -//! ## Usage |
| 19 | +//! # Usage |
20 | 20 | //!
|
21 | 21 | //! The `format!` macro is intended to be familiar to those coming from C's
|
22 | 22 | //! printf/fprintf functions or Python's `str.format` function. In its current
|
|
41 | 41 | //! will then parse the format string and determine if the list of arguments
|
42 | 42 | //! provided is suitable to pass to this format string.
|
43 | 43 | //!
|
44 |
| -//! ### Positional parameters |
| 44 | +//! ## Positional parameters |
45 | 45 | //!
|
46 | 46 | //! Each formatting argument is allowed to specify which value argument it's
|
47 | 47 | //! referencing, and if omitted it is assumed to be "the next argument". For
|
|
54 | 54 | //! iterator over the argument. Each time a "next argument" specifier is seen,
|
55 | 55 | //! the iterator advances. This leads to behavior like this:
|
56 | 56 | //!
|
57 |
| -//! ```rust |
| 57 | +//! ``` |
58 | 58 | //! format!("{1} {} {0} {}", 1, 2); // => "2 1 1 2"
|
59 | 59 | //! ```
|
60 | 60 | //!
|
|
68 | 68 | //! compile-time error. You may refer to the same argument more than once in the
|
69 | 69 | //! format string, although it must always be referred to with the same type.
|
70 | 70 | //!
|
71 |
| -//! ### Named parameters |
| 71 | +//! ## Named parameters |
72 | 72 | //!
|
73 | 73 | //! Rust itself does not have a Python-like equivalent of named parameters to a
|
74 | 74 | //! function, but the `format!` macro is a syntax extension which allows it to
|
|
91 | 91 | //! arguments which have names. Like with positional parameters, it is illegal
|
92 | 92 | //! to provide named parameters that are unused by the format string.
|
93 | 93 | //!
|
94 |
| -//! ### Argument types |
| 94 | +//! ## Argument types |
95 | 95 | //!
|
96 | 96 | //! Each argument's type is dictated by the format string. It is a requirement
|
97 | 97 | //! that every argument is only ever referred to by one type. For example, this
|
|
116 | 116 | //! {:.*} {0}
|
117 | 117 | //! ```
|
118 | 118 | //!
|
119 |
| -//! ### Formatting traits |
| 119 | +//! ## Formatting traits |
120 | 120 | //!
|
121 | 121 | //! When requesting that an argument be formatted with a particular type, you
|
122 | 122 | //! are actually requesting that an argument ascribes to a particular trait.
|
|
142 | 142 | //! When implementing a format trait for your own type, you will have to
|
143 | 143 | //! implement a method of the signature:
|
144 | 144 | //!
|
145 |
| -//! ```rust |
| 145 | +//! ``` |
146 | 146 | //! # use std::fmt;
|
147 | 147 | //! # struct Foo; // our custom type
|
148 | 148 | //! # impl fmt::Display for Foo {
|
|
166 | 166 | //! An example of implementing the formatting traits would look
|
167 | 167 | //! like:
|
168 | 168 | //!
|
169 |
| -//! ```rust |
| 169 | +//! ``` |
170 | 170 | //! use std::fmt;
|
171 | 171 | //! use std::f64;
|
172 | 172 | //! use std::num::Float;
|
|
211 | 211 | //! }
|
212 | 212 | //! ```
|
213 | 213 | //!
|
214 |
| -//! #### fmt::Display vs fmt::Debug |
| 214 | +//! ### fmt::Display vs fmt::Debug |
215 | 215 | //!
|
216 | 216 | //! These two formatting traits have distinct purposes:
|
217 | 217 | //!
|
|
231 | 231 | //! assert_eq!(format!("{} {:?}", "foo\n", "bar\n"), "foo\n \"bar\\n\"");
|
232 | 232 | //! ```
|
233 | 233 | //!
|
234 |
| -//! ### Related macros |
| 234 | +//! ## Related macros |
235 | 235 | //!
|
236 | 236 | //! There are a number of related macros in the `format!` family. The ones that
|
237 | 237 | //! are currently implemented are:
|
|
245 | 245 | //! format_args! // described below.
|
246 | 246 | //! ```
|
247 | 247 | //!
|
248 |
| -//! #### `write!` |
| 248 | +//! ### `write!` |
249 | 249 | //!
|
250 | 250 | //! This and `writeln` are two macros which are used to emit the format string
|
251 | 251 | //! to a specified stream. This is used to prevent intermediate allocations of
|
252 | 252 | //! format strings and instead directly write the output. Under the hood, this
|
253 | 253 | //! function is actually invoking the `write` function defined in this module.
|
254 | 254 | //! Example usage is:
|
255 | 255 | //!
|
256 |
| -//! ```rust |
| 256 | +//! ``` |
257 | 257 | //! # #![allow(unused_must_use)]
|
258 | 258 | //! let mut w = Vec::new();
|
259 | 259 | //! write!(&mut w, "Hello {}!", "world");
|
260 | 260 | //! ```
|
261 | 261 | //!
|
262 |
| -//! #### `print!` |
| 262 | +//! ### `print!` |
263 | 263 | //!
|
264 | 264 | //! This and `println` emit their output to stdout. Similarly to the `write!`
|
265 | 265 | //! macro, the goal of these macros is to avoid intermediate allocations when
|
266 | 266 | //! printing output. Example usage is:
|
267 | 267 | //!
|
268 |
| -//! ```rust |
| 268 | +//! ``` |
269 | 269 | //! print!("Hello {}!", "world");
|
270 | 270 | //! println!("I have a newline {}", "character at the end");
|
271 | 271 | //! ```
|
272 | 272 | //!
|
273 |
| -//! #### `format_args!` |
| 273 | +//! ### `format_args!` |
| 274 | +//! |
274 | 275 | //! This is a curious macro which is used to safely pass around
|
275 | 276 | //! an opaque object describing the format string. This object
|
276 | 277 | //! does not require any heap allocations to create, and it only
|
|
303 | 304 | //! it would internally pass around this structure until it has been determined
|
304 | 305 | //! where output should go to.
|
305 | 306 | //!
|
306 |
| -//! ## Syntax |
| 307 | +//! # Syntax |
307 | 308 | //!
|
308 | 309 | //! The syntax for the formatting language used is drawn from other languages,
|
309 | 310 | //! so it should not be too alien. Arguments are formatted with python-like
|
|
326 | 327 | //! parameter := integer '$'
|
327 | 328 | //! ```
|
328 | 329 | //!
|
329 |
| -//! ## Formatting Parameters |
| 330 | +//! # Formatting Parameters |
330 | 331 | //!
|
331 | 332 | //! Each argument being formatted can be transformed by a number of formatting
|
332 | 333 | //! parameters (corresponding to `format_spec` in the syntax above). These
|
333 | 334 | //! parameters affect the string representation of what's being formatted. This
|
334 | 335 | //! syntax draws heavily from Python's, so it may seem a bit familiar.
|
335 | 336 | //!
|
336 |
| -//! ### Fill/Alignment |
| 337 | +//! ## Fill/Alignment |
337 | 338 | //!
|
338 | 339 | //! The fill character is provided normally in conjunction with the `width`
|
339 | 340 | //! parameter. This indicates that if the value being formatted is smaller than
|
|
345 | 346 | //! * `^` - the argument is center-aligned in `width` columns
|
346 | 347 | //! * `>` - the argument is right-aligned in `width` columns
|
347 | 348 | //!
|
348 |
| -//! ### Sign/#/0 |
| 349 | +//! ## Sign/#/0 |
349 | 350 | //!
|
350 | 351 | //! These can all be interpreted as flags for a particular formatter.
|
351 | 352 | //!
|
|
368 | 369 | //! same format would yield `-0000001` for the integer `-1`. Notice that
|
369 | 370 | //! the negative version has one fewer zero than the positive version.
|
370 | 371 | //!
|
371 |
| -//! ### Width |
| 372 | +//! ## Width |
372 | 373 | //!
|
373 | 374 | //! This is a parameter for the "minimum width" that the format should take up.
|
374 | 375 | //! If the value's string does not fill up this many characters, then the
|
|
384 | 385 | //! parameters by using the `2$` syntax indicating that the second argument is a
|
385 | 386 | //! `usize` specifying the width.
|
386 | 387 | //!
|
387 |
| -//! ### Precision |
| 388 | +//! ## Precision |
388 | 389 | //!
|
389 | 390 | //! For non-numeric types, this can be considered a "maximum width". If the
|
390 | 391 | //! resulting string is longer than this width, then it is truncated down to
|
|
395 | 396 | //! For floating-point types, this indicates how many digits after the decimal
|
396 | 397 | //! point should be printed.
|
397 | 398 | //!
|
398 |
| -//! ## Escaping |
| 399 | +//! # Escaping |
399 | 400 | //!
|
400 | 401 | //! The literal characters `{` and `}` may be included in a string by preceding
|
401 | 402 | //! them with the same character. For example, the `{` character is escaped with
|
|
0 commit comments