mapping to non-interior fields

[nikomatsakis]

The RFC as currently written only permits mapping to interior fields (i.e., things that can be reached via some byte offset from a self pointer). The main motivation for this is to permit faster trait objects (i.e., we only have to load an offset from the vtable). I now think this is the wrong trade-off. We should by flexible by default but support #[repr] annotations that impose stricter limitations on impls.

One example where this would be useful is that we could support passing through &T values:

trait Foo { t: u32 }
impl Foo for &mut u32 {
    t = *self
}

However, there are some limitations related to the Deref impl if you try to go beyond & types. For example, if one were to do:

trait Foo { f: u32, g: u32 }
impl Foo for Box<(u32, u32)> {
    f = self.0,
    g = self.1;
}

The borrow checker would be upset (https://is.gd/getwoD). This is because, when you desugar self.0, you are actually first doing let tmp1 = DerefMut::deref_mut(self) and then &mut tmp1.0. And the same for self.1, which desugars to let tmp2 = DerefMut::deref_mut(self). We can't allow those two temporaries to overlap.

[burdges]

In this example, you could write (ref mut f, ref mut g) = foo.deref_mut(); bar(f,g); but not bar(&mut foo.f,&mut foo.g); or even Foo { ref mut f, ref mut g } = foo.deref_mut(); bar(f,g); if you guys allow patterns. It feels slightly more opaque than many borrow checker errors, especially if folks are told to use trait fields [instead of accessors] to help pacify the borrow checker. Not a big deal, just noticing.

I suppose this works :

trait Foo { f: u32, g: u32 }
trait FooHelper : Foo { s: (u32, u32) }
impl FooHelper for Box<(u32, u32)> {
    s = *self.deref_mut()
}
impl Foo for Box<(u32, u32)> {
    f = s.0,
    g = s.1;
}

[djdisodo]

won't deref be implemented by trait fields when this arrives?
(so we can just put something like Deref::target)