|
50 | 50 | //! The internal iterator over the argument has not been advanced by the time |
51 | 51 | //! the first `{}` is seen, so it prints the first argument. Then upon reaching |
52 | 52 | //! the second `{}`, the iterator has advanced forward to the second argument. |
53 | | -//! Essentially, parameters which explicitly name their argument do not affect |
54 | | -//! parameters which do not name an argument in terms of positional specifiers. |
| 53 | +//! Essentially, parameters that explicitly name their argument do not affect |
| 54 | +//! parameters that do not name an argument in terms of positional specifiers. |
55 | 55 | //! |
56 | 56 | //! A format string is required to use all of its arguments, otherwise it is a |
57 | 57 | //! compile-time error. You may refer to the same argument more than once in the |
|
60 | 60 | //! ## Named parameters |
61 | 61 | //! |
62 | 62 | //! Rust itself does not have a Python-like equivalent of named parameters to a |
63 | | -//! function, but the [`format!`] macro is a syntax extension which allows it to |
| 63 | +//! function, but the [`format!`] macro is a syntax extension that allows it to |
64 | 64 | //! leverage named parameters. Named parameters are listed at the end of the |
65 | 65 | //! argument list and have the syntax: |
66 | 66 | //! |
|
77 | 77 | //! ``` |
78 | 78 | //! |
79 | 79 | //! It is not valid to put positional parameters (those without names) after |
80 | | -//! arguments which have names. Like with positional parameters, it is not |
| 80 | +//! arguments that have names. Like with positional parameters, it is not |
81 | 81 | //! valid to provide named parameters that are unused by the format string. |
82 | 82 | //! |
83 | 83 | //! # Formatting Parameters |
|
130 | 130 | //! |
131 | 131 | //! The default [fill/alignment](#fillalignment) for non-numerics is a space and |
132 | 132 | //! left-aligned. The |
133 | | -//! defaults for numeric formatters is also a space but with right-alignment. If |
| 133 | +//! default for numeric formatters is also a space character but with right-alignment. If |
134 | 134 | //! the `0` flag (see below) is specified for numerics, then the implicit fill character is |
135 | 135 | //! `0`. |
136 | 136 | //! |
|
161 | 161 | //! `Signed` trait. This flag indicates that the correct sign (`+` or `-`) |
162 | 162 | //! should always be printed. |
163 | 163 | //! * `-` - Currently not used |
164 | | -//! * `#` - This flag is indicates that the "alternate" form of printing should |
| 164 | +//! * `#` - This flag indicates that the "alternate" form of printing should |
165 | 165 | //! be used. The alternate forms are: |
166 | 166 | //! * `#?` - pretty-print the [`Debug`] formatting |
167 | 167 | //! * `#x` - precedes the argument with a `0x` |
|
173 | 173 | //! like `{:08}` would yield `00000001` for the integer `1`, while the |
174 | 174 | //! same format would yield `-0000001` for the integer `-1`. Notice that |
175 | 175 | //! the negative version has one fewer zero than the positive version. |
176 | | -//! Note that padding zeroes are always placed after the sign (if any) |
| 176 | +//! Note that padding zeros are always placed after the sign (if any) |
177 | 177 | //! and before the digits. When used together with the `#` flag, a similar |
178 | | -//! rule applies: padding zeroes are inserted after the prefix but before |
| 178 | +//! rule applies: padding zeros are inserted after the prefix but before |
179 | 179 | //! the digits. The prefix is included in the total width. |
180 | 180 | //! |
181 | 181 | //! ## Precision |
|
251 | 251 | //! |
252 | 252 | //! In some programming languages, the behavior of string formatting functions |
253 | 253 | //! depends on the operating system's locale setting. The format functions |
254 | | -//! provided by Rust's standard library do not have any concept of locale, and |
| 254 | +//! provided by Rust's standard library do not have any concept of locale and |
255 | 255 | //! will produce the same results on all systems regardless of user |
256 | 256 | //! configuration. |
257 | 257 | //! |
|
470 | 470 | //! |
471 | 471 | //! ### `format_args!` |
472 | 472 | //! |
473 | | -//! This is a curious macro which is used to safely pass around |
| 473 | +//! This is a curious macro used to safely pass around |
474 | 474 | //! an opaque object describing the format string. This object |
475 | 475 | //! does not require any heap allocations to create, and it only |
476 | 476 | //! references information on the stack. Under the hood, all of |
|
495 | 495 | //! This structure can then be passed to the [`write`] and [`format`] functions |
496 | 496 | //! inside this module in order to process the format string. |
497 | 497 | //! The goal of this macro is to even further prevent intermediate allocations |
498 | | -//! when dealing formatting strings. |
| 498 | +//! when dealing with formatting strings. |
499 | 499 | //! |
500 | 500 | //! For example, a logging library could use the standard formatting syntax, but |
501 | 501 | //! it would internally pass around this structure until it has been determined |
|
0 commit comments