diff --git a/text/0000-no-array-elem-moves.md b/text/0000-no-array-elem-moves.md
index 35d1b20b2b0..bca8a1f5978 100644
--- a/text/0000-no-array-elem-moves.md
+++ b/text/0000-no-array-elem-moves.md
@@ -9,7 +9,7 @@ In order to prepare for an expected future implementation of
 
 * moving individual elements into an *uninitialized* fixed-sized array, and
 
-* moving individual elements out of fixed-sized arrays `[T, ..n]`,
+* moving individual elements out of fixed-sized arrays `[T; n]`,
   (copying and borrowing such elements is still permitted).
 
 [non-zeroing dynamic drop]: https://github.com/rust-lang/rfcs/pull/320
@@ -36,10 +36,10 @@ will present relatively little burden.
 
 # Detailed design
 
-If an expression `e` has type `[T, ..n]` and `T` does not implement
+If an expression `e` has type `[T; n]` and `T` does not implement
 `Copy`, then it will be illegal to use `e[i]` in an r-value position.
 
-If an expression `e` has type `[T, ..n]` expression `e[i] = <expr>`
+If an expression `e` has type `[T; n]` expression `e[i] = <expr>`
 will be made illegal at points in the control flow where `e` has not
 yet been initialized.
 
@@ -47,8 +47,13 @@ Note that it *remains* legal to overwrite an element in an initialized
 array: `e[i] = <expr>`, as today.  This will continue to drop the
 overwritten element before moving the result of `<expr>` into place.
 
-A prototype implementation will be made available before this RFC is
-accepted.
+Note also that the proposed change has no effect on the semantics of
+destructuring bind; i.e. `fn([a, b, c]: [Elem; 3]) { ... }` will
+continue to work as much as it does today.
+
+A prototype implementation has been posted at [Rust PR 21930].
+
+[Rust PR 21930]: https://github.com/rust-lang/rust/pull/21930
 
 # Drawbacks
 
@@ -62,11 +67,13 @@ Also, as noted in the [comment thread from RFC PR 320]
 [comment thread from RFC PR 320]: https://github.com/rust-lang/rfcs/pull/320#issuecomment-59533551
 
 * We support moving a single element out of an n-tuple, and "by
-  analogy" we should support moving out of `[T, ..n]`
+  analogy" we should support moving out of `[T; n]`
+  (Note that one can still move out of `[T; n]` in some cases
+  via destructuring bind.)
 
 * It is "nice" to be able to write
   ```rust
-  fn grab_random_from(actions: [Action, ..5]) -> Action { actions[rand_index()] }
+  fn grab_random_from(actions: [Action; 5]) -> Action { actions[rand_index()] }
   ```
   to express this now, one would be forced to instead use clone() (or
   pass in a `Vec` and do some element swapping).