|
2 | 2 |
|
3 | 3 | ## Summary
|
4 | 4 |
|
5 |
| -- `any_prefix#..`, `any_prefix".."`, and `any_prefix'..'` are reserved syntax, and no longer tokenize. |
| 5 | +- `any_prefix#`, `any_prefix"..."`, and `any_prefix'...'` are now reserved |
| 6 | + syntax, and no longer tokenize. |
6 | 7 | - This is mostly relevant to macros. E.g. `quote!{ #a#b }` is no longer accepted.
|
7 | 8 | - It doesn't treat keywords specially, so e.g. `match".." {}` is no longer accepted.
|
8 | 9 | - Insert whitespace to avoid errors.
|
9 | 10 |
|
10 | 11 | ## Details
|
11 | 12 |
|
12 |
| -To make space for some new syntax in the future, |
| 13 | +To make space for new syntax in the future, |
13 | 14 | we've decided to reserve syntax for prefixed identifiers and literals:
|
14 | 15 | `prefix#identifier`, `prefix"string"`, `prefix'c'`, and `prefix#123`,
|
15 | 16 | where `prefix` can be any identifier.
|
16 | 17 | (Except those that already have a meaning, such as `b'…'` and `r"…"`.)
|
| 18 | +This provides syntax we can expand into in the future without requiring an |
| 19 | +edition boundary. We may use that for temporary syntax until the next edition, |
| 20 | +or for permanent syntax if appropriate. |
17 | 21 |
|
18 |
| -This is a breaking change, since macros can currently accept `hello"world"`, |
19 |
| -which they will see as two separate tokens: `hello` and `"world"`. |
20 |
| -The (automatic) fix is simple though. Just insert a space: `hello "world"`. |
21 |
| - |
22 |
| -<!-- |
23 |
| -The original plan was to reserve only `k#` and `f""` for future use, |
24 |
| -but reserving *all* possible prefixes did not have many downsides. |
25 |
| -It leaves more space for new syntax which would otherwise need to wait for another edition. |
26 |
| ---> |
| 22 | +Without an edition, this would be a breaking change, since macros can currently |
| 23 | +accept syntax such as `hello"world"`, which they will see as two separate |
| 24 | +tokens: `hello` and `"world"`. The (automatic) fix is simple though: just |
| 25 | +insert a space: `hello "world"`. Likewise, `prefix#ident` should become |
| 26 | +`prefix #ident`. |
27 | 27 |
|
28 | 28 | Other than turning these into a tokenization error,
|
29 | 29 | [the RFC][10] does not attach a meaning to any prefix yet.
|
30 | 30 | Assigning meaning to specific prefixes is left to future proposals,
|
31 |
| -which will—thanks to reserving these prefixes now—not be breaking changes. |
32 |
| - |
33 |
| -These are some new prefixes you might see in the future: |
| 31 | +which will now—thanks to reserving these prefixes—not be breaking changes. |
34 | 32 |
|
35 |
| -- `f""` as a short-hand for a format string. |
36 |
| - For example, `f"hello {name}"` as a short-hand for the equivalent `format_args!()` invocation. |
37 |
| - |
38 |
| -- `c""` or `z""` for null-terminated C strings. |
| 33 | +Some new prefixes you might potentially see in the future (though we haven't |
| 34 | +committed to any of them yet): |
39 | 35 |
|
40 | 36 | - `k#keyword` to allow writing keywords that don't exist yet in the current edition.
|
41 | 37 | For example, while `async` is not a keyword in edition 2015,
|
42 | 38 | this prefix would've allowed us to accept `k#async` in edition 2015
|
43 | 39 | without having to wait for edition 2018 to reserve `async` as a keyword.
|
44 | 40 |
|
| 41 | +- `f""` as a short-hand for a format string. |
| 42 | + For example, `f"hello {name}"` as a short-hand for the equivalent `format!()` invocation. |
| 43 | + |
| 44 | +- `s""` for `String` literals. |
| 45 | + |
| 46 | +- `c""` or `z""` for null-terminated C strings. |
| 47 | + |
45 | 48 | [10]: https://github.com/rust-lang/rfcs/pull/3101
|
0 commit comments