Using `&mut io::Writer` might be too difficult

[alexcrichton]

I figured that with the advent of traits working and &mut io::Writer, we would want to write lots of code that only takes &mut io::Writer to pass streams around.

It turns out though that if you squirrel these away in structs, they can't ever really get moved out. For example, this code fails to compile

use std::rt::io;

struct HttpResponse<'self> {
    out: &'self mut io::Writer,
}

fn write_http_header(_: &mut io::Writer) {}

impl<'self> HttpResponse<'self> {
    fn respond(&mut self) {
        write_http_header(self.out);
    }
}

fn main() {}

foo.rs:11:26: 11:34 error: cannot move out of dereference of & pointer
foo.rs:11         write_http_header(self.out);
                                    ^~~~~~~~
error: aborting due to previous error

The specific example I hit was when I was ripping out @::std::io::Writer from std::repr. At some point the visitor decides to give its buffer to a child visitor for the small duration of a call, and there's also a point where it shoves passes the buffer directly to an object's write_repr method.

The errors are completely legitimate (given what I believe are today's region rules for &mut). That being said however, it seems like a fairly common use-case. Tweaking the rules to realize that this is safe could be quite difficult, but perhaps it's possible?

If this doesn't turn out to be a common case, then there's really no need to deal with it. For now I've resorted to using transmute_copy in a few places in #8414

cc @brson for io::Writer feedback
cc @nikomatsakis for if rules would be impossible to tweak

[huonw]

Does reborrowing via write_http_header(&mut *self.out) work?

[alexcrichton]

Sadly no, that bails out with

error: type &'self mut std::rt::io::Writer<no-bounds> cannot be dereferenced

[huonw]

Oh, right, trait objects. Maybe the horror &mut &mut Writer works as a temporary measure?

[alexcrichton]

The bad part is that if you're writing generic code you don't want to take &mut &mut as a parameter and then after that you face the same problem in that you can't move out of that once it's in a structure as well.

[huonw]

I think that the double indirection would allow it to be reborrowed. Also generic code would be something like fn foo<W: Writer>(w: &mut W), and so for a trait object this would take W = &mut Writer, i.e w: &mut &mut Writer.

(I'm not near a rustc to test atm, however.)

[alexcrichton]

After talking with @huonw on IRC, here's what we came up with:

This primarily affects a situation where library A has a function which takes &mut io::Writer and you're writing program B which wants to call library A. It turns out your writer is stored as &mut io::Writer in a struct and you just want to give it on loan to someone else.

It looked like (from a pull request a long time ago) that the intention is for objects to be automatically coercible into traits, so perhaps an object of the type &mut &mut io::Writer could be automatically coerced into &mut io::Writer somehow by the compiler? It would be a bit of a shame to have to implement the trait for only this case because other traits wouldn't benefit.

Not sure if that's a sound solution though.

[nikomatsakis]

Wait wait wait. These should reborrow -- I just landed a PR recently that aimed to fix this, let me experiment.

[nikomatsakis]

Please re-test -- I believe your original example works now.

[alexcrichton]

Sorry for the false alarm, you are correct @nikomatsakis, it works!