| 
 | 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