RFC 693 is merged. Update links and so forth.

README.md

@@ -39,6 +39,7 @@ the direction the language is evolving in.
 * [0509-collections-reform-part-2.md](text/0509-collections-reform-part-2.md)
 * [0517-io-os-reform.md](text/0517-io-os-reform.md)
 * [0560-integer-overflow.md](text/0560-integer-overflow.md)
+* [0639-discriminant-intrinsic.md](text/0639-discriminant-intrinsic.md)
 * [0769-sound-generic-drop.md](text/0769-sound-generic-drop.md)
 * [0803-type-ascription.md](text/0803-type-ascription.md)
 * [0809-box-and-in-for-stdlib.md](text/0809-box-and-in-for-stdlib.md)

text/0000-variadic-generics.md

@@ -0,0 +1,46 @@
+- Feature Name: variadic-generics
+- Start Date: 2015-04-03
+- RFC PR: (leave this empty)
+- Rust Issue: (leave this empty)
+
+# Summary
+
+
+# Motivation
+
+Why are we doing this? What use cases does it support? What is the expected outcome?
+
+# Detailed design
+
+## Introduce the `Tuple` trait
+
+The `Tuple` trait is implemented for tuples of any arity. It is a lang
+item.
+
+```rust
+trait Tuple { }
+```
+
+## Expandable parameters
+
+In a `fn` signature, a `..` may appear before the type of any
+argument. This type must implement the `Tuple` trait. The `..`
+indicates that the single 
+
+```rust
+trait Fn<A:Tuple>: FnMut<A> {
+    fn call(&self, args: ..A) -> Self::Output;
+}
+```
+
+# 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?

text/0000-discriminant-intrinsic.md → text/0639-discriminant-intrinsic.md

@@ -1,6 +1,6 @@
 - Start Date: 2015-01-21
-- RFC PR: (leave this empty)
-- Rust Issue: (leave this empty)
+- RFC PR: [rust-lang/rfcs#639](https://github.com/rust-lang/rfcs/pull/639)
+- Rust Issue: [rust-lang/rust#24263](https://github.com/rust-lang/rust/issues/24263)
 
 # Summary
 
@@ -341,4 +341,19 @@ pub enum SqlState {
     IndexCorrupted,
     Unknown(String),
 }
-```
+```
+
+# History
+
+This RFC was accepted on a provisional basis on 2015-10-04.  The
+intention is to implement and experiment with the proposed
+intrinsic. Some concerns expressed in the RFC discussion that will
+require resolution before the RFC can be fully accepted:
+
+- Using bounds such as `T:Reflect` to help ensure parametricity.
+- Do we want to change the return type in some way?
+  - It may not be helpful if we expose discriminant directly in the
+    case of (potentially) negative discriminants.
+  - We might want to return something more opaque to guard against
+    unintended representation exposure.
+- Does this intrinsic need to be unsafe?