|
| 1 | +- Feature Name: static_lifetime_in_statics |
| 2 | +- Start Date: 2016-05-20 |
| 3 | +- RFC PR: (leave this empty) |
| 4 | +- Rust Issue: (leave this empty) |
| 5 | + |
| 6 | +# Summary |
| 7 | +[summary]: #summary |
| 8 | + |
| 9 | +Let's default lifetimes in static and const declarations to `'static`. |
| 10 | + |
| 11 | +# Motivation |
| 12 | +[motivation]: #motivation |
| 13 | + |
| 14 | +Currently, having references in `static` and `const` declarations is cumbersome |
| 15 | +due to having to explicitly write `&'static ..`. On the other hand anything but |
| 16 | +static is likely either useless, unsound or both. Also the long lifetime name |
| 17 | +causes substantial rightwards drift, which makes it hard to format the code |
| 18 | +to be visually appealing. |
| 19 | + |
| 20 | +For example, having a `'static` default for lifetimes would turn this: |
| 21 | +``` |
| 22 | +static my_awesome_tables: &'static [&'static HashMap<Cow<'static, str>, u32>] = .. |
| 23 | +``` |
| 24 | +into this: |
| 25 | +``` |
| 26 | +static my_awesome_table: &[&HashMap<Cow<str>, u32>] = .. |
| 27 | +``` |
| 28 | + |
| 29 | +The type declaration still causes some rightwards drift, but at least all the |
| 30 | +contained information is useful. |
| 31 | + |
| 32 | +# Detailed design |
| 33 | +[design]: #detailed-design |
| 34 | + |
| 35 | +The same default that RFC #599 sets up for trait object is to be used for |
| 36 | +statics and const declarations. In those declarations, the compiler will assume |
| 37 | +`'static` when a lifetime is not explicitly given in both refs and generics. |
| 38 | + |
| 39 | +Note that this RFC does not forbid writing the lifetimes, it only sets a |
| 40 | +default when no is given. Thus the change is unlikely to cause any breakage and |
| 41 | +should be deemed backwards-compatible. It's also very unlikely that |
| 42 | +implementing this RFC will restrict our design space for `static` and `const` |
| 43 | +definitions down the road. |
| 44 | + |
| 45 | +# Drawbacks |
| 46 | +[drawbacks]: #drawbacks |
| 47 | + |
| 48 | +There are no known drawbacks to this change. |
| 49 | + |
| 50 | +# Alternatives |
| 51 | +[alternatives]: #alternatives |
| 52 | + |
| 53 | +* Leave everything as it is. Everyone using static references is annoyed by |
| 54 | +having to add `'static` without any value to readability. People will resort to |
| 55 | +writing macros if they have many resources. |
| 56 | +* Write the aforementioned macro. This is inferior in terms of UX. Depending on |
| 57 | +the implementation it may or may not be possible to default lifetimes in |
| 58 | +generics. |
| 59 | +* Infer types for statics. The absence of types makes it harder to reason about |
| 60 | +the code, so even if type inference for statics was to be implemented, |
| 61 | +defaulting lifetimes would have the benefit of pulling the cost-benefit |
| 62 | +relation in the direction of more explicit code. Thus it is advisable to |
| 63 | +implement this change even with the possibility of implementing type inference |
| 64 | +later. |
| 65 | + |
| 66 | +# Unresolved questions |
| 67 | +[unresolved]: #unresolved-questions |
| 68 | + |
| 69 | +* Does this change requires changing the grammar? |
| 70 | +* Are there other Rust-code handling programs that need to be updated? |
0 commit comments