diff --git a/0000-fn-lifetimes.md b/0000-fn-lifetimes.md
new file mode 100644
index 00000000000..dfe5f470752
--- /dev/null
+++ b/0000-fn-lifetimes.md
@@ -0,0 +1,33 @@
+- Start Date: (fill me in with today's date, YYYY-MM-DD)
+- RFC PR: (leave this empty)
+- Rust Issue: (leave this empty)
+
+# Summary
+
+The current `fn()` types represent something close to `&'static Code`, which means that safely representing a function pointer into code with a non-static lifetime safely is impossible. This RFC describes the addition of the ability to assign a non-static lifetime to the `fn()` type, which would allow `fn():'a` to represent a type similar to `&'a Code`.
+
+# Motivation
+
+This is useful in safely handling plugins, as any function pointer into the plugin could be guaranteed not to outlive the plugin itself. It's also necessary to ensure safety in instances where dynamic code generation is taking place, such as a JIT (just-in-time compilation) engine.
+
+# Detailed design
+The syntax for an `fn()` type with the lifetime 'a and return type R would be:
+```
+fn():'a -> R
+```
+This grammar would accept any lifetime. A function pointer is always contravariant with regard to its lifetime.
+This makes the `fn():'a` type roughly equivalent to the `||:'a` type without an environment.
+To maintain backwards compability and code cleanness, the current syntax would imply a 'static lifetime bound.
+
+# Drawbacks
+
+This may introduce further complexity into borrowck.
+
+# Alternatives
+
+Turn `fn()` into a quasi-unsized type, in such a way that the current `fn()` would represent `&'static fn()`.
+
+# Unresolved questions
+
+Should eliding the lifetime lead to it being inferred (as per the lifetime elision RFC) or default to 'static?
+One proposal is to have `fn():` represent an elided lifetime, and `fn()` a static one.
diff --git a/0000-template.md b/0000-template.md
deleted file mode 100644
index d1dad5534c6..00000000000
--- a/0000-template.md
+++ /dev/null
@@ -1,29 +0,0 @@
-- Start Date: (fill me in with today's date, YYYY-MM-DD)
-- RFC PR: (leave this empty)
-- Rust Issue: (leave this empty)
-
-# Summary
-
-One para explanation of the feature.
-
-# Motivation
-
-Why are we doing this? What use cases does it support? What is the expected outcome?
-
-# Detailed design
-
-This is the bulk of the RFC. Explain the design in enough detail for somebody familiar
-with the language to understand, and for somebody familiar with the compiler to implement.
-This should get into specifics and corner-cases, and include examples of how the feature is used.
-
-# Drawbacks
-
-Why should we *not* do this?
-
-# Alternatives
-
-What other designs have been considered? What is the impact of not doing this?
-
-# Unresolved questions
-
-What parts of the design are still TBD?