Skip to content

Commit 48ac001

Browse files
committed
new RFC: static_lifetime_in_statics
1 parent a4a22d7 commit 48ac001

File tree

1 file changed

+70
-0
lines changed

1 file changed

+70
-0
lines changed

text/0000-static.md

Lines changed: 70 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,70 @@
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

Comments
 (0)