Misleading synopsis of self-references in readme

[dtolnay]

The following excerpts from https://github.com/petrosagg/escher/tree/016f4c10491741690411d7b5a080218d8399b693#the-problem-with-self-references:

The main problem with self-referencial structs is that if such a struct was somehow constructed the compiler would then have to statically prove that it would not move again. [...]

[...] imagine we define a self-referencial struct that holds a Vec and a pointer to it at the same time:

struct Foo {
    s: Vec<u8>,
    p: &Vec<u8>,
}

Then, let's assume we had a way of getting an instance of this struct. [...]

This wording heavily implies that you can't already create or manipulate such a struct in safe Rust, which isn't accurate. In particular:

• "if such a struct was somehow constructed" -- in fact it's totally possible to construct such a struct
• "let's assume we had a way of getting an instance of this struct" -- we do have this
• "the compiler would then have to statically prove that it would not move again" -- yes, the compiler does this
• "We could then write the following code that creates a dangling pointer in safe rust!" -- this statement does not follow, specifically because the compiler statically proves that you don't move the struct

Example code:

#[derive(Debug)]
struct Foo<'a> {
    s: Vec<u8>,
    p: &'a Vec<u8>,
}

fn main() {
    let mut foo = Foo {
        s: vec![1, 1, 1, 1],
        p: &Vec::new(), // tmp
    };
    foo.p = &foo.s;
    println!("{:?}", foo);
}

Foo { s: [1, 1, 1, 1], p: [1, 1, 1, 1] }

This constructs the self-referential struct described in the readme, and runs its Debug impl.