Add future work section for MaybeUninit etc.

Author: adetaylor

text/3519-arbitrary-self-types-v2.md

@@ -555,6 +555,30 @@ Even if the reader takes the view that all calls into foreign languages are intr
 
 A previous PR based on the `Deref` alternative has been proposed before https://github.com/rust-lang/rfcs/pull/2362 and was postponed with the expectation that the lang team would [get back to `arbitrary_self_types` eventually](https://github.com/rust-lang/rfcs/pull/2362#issuecomment-527306157).
 
+# Future work
+
+We could consider implementing `Receiver` for other types, e.g. [`std::cell`](https://doc.rust-lang.org/std/cell/index.html) types, [`std::sync`](https://doc.rust-lang.org/std/sync/index.html) types, [`std::cmp::Reverse`](https://doc.rust-lang.org/std/cmp/struct.Reverse.html), [`std::num::Wrapping`](https://doc.rust-lang.org/nightly/std/num/struct.Wrapping.html), [`std::mem::MaybeUninit`](https://doc.rust-lang.org/std/mem/union.MaybeUninit.html), [`std::task::Poll`](https://doc.rust-lang.org/nightly/std/task/enum.Poll.html), and so on - possibly even for arrays, `Vec`, `BTreeSet` etc.
+
+There seems to be no disadvantage to doing this - taking `Vec` as an example, it would only have any effect on the behavior of code if somebody implemented a method taking `Vec<T>` as a receiver. On the other hand, it's hard to imagine use-cases for some of these. It seems best to consider these future possibilities based on whether the end-result seems natural or strange.
+
+```rust
+impl Vexation {
+    fn do_something_to_vec(self: Vec<Self>) { }
+    fn do_something_to_maybeuninit(self: MaybeUninit<Self>) {}
+}
+
+fn main {
+    let v = Vec::new();
+    v.push(Vexation);
+    v.do_something_to_vec(); // this seems weird and I can't imagine a use-case
+
+    let mut m = MaybeUninit::<Vexation>::uninit();
+    m.do_something_to_maybeuninit(); // this seems fine and useful and so maybe we should in future implement Receiver for MaybeUninit
+}
+```
+
+For now, though, we should clearly restrict `Receiver` to those types for which there's a demonstrated need.
+
 # Feature gates
 
 This RFC is in an unusual position regarding feature gates. There are two existing gates: