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