No way to get Box<X> out of a Box<X + Y>

[reem]

There is currently no way to get a Box<Reader> (or anything else that impls Reader) out of a Box<Reader + Constraint>, for instance Box<Reader + Send>. This is a significant ergonomic problem.

Additionally, Box<Reader + Constraint> should impl Reader since Box<Reader> impls Reader.

[hexsel]

Is this not a more generic case of #15906?

[reem]

Oops, yes it is. I had forgotten I filed that issue.

[Gankra]

A fun variant of this; cannot dereferrence Deref<int> + 'static:

use std::rc::Rc;

struct Foo {
    foo: Box<Deref<int> + 'static>,
}

fn main() {
    let foo = Foo{foo: box Rc::new(0) };
    println!("{}", (*foo.foo).deref()); // I work
    println!("{}", **foo.foo); // I don't
}

playpen

[steveklabnik]

I'm pulling a massive triage effort to get us ready for 1.0. As part of this, I'm moving stuff that's wishlist-like to the RFCs repo, as that's where major new things should get discussed/prioritized.

This issue has been moved to the RFCs repo: rust-lang/rfcs#761

[reem]

@steveklabnik I disagree that this is not just a bug, and think it should remain an issue here and not in the rfcs repo. There is no need to change the language for this - it's just a matter of implementation.

[steveklabnik]

A clarifying comment on IRC:

04:24 < reem> Really the issue is that impls for Box<X> do 
              not apply to Box<X + Y>, which really just 
              looks like a bug.
04:24 < reem> I think there is already agreement that that 
              is the desired semantics, though I could be 
              wrong.

[steveklabnik]

Triage: no changes that I'm aware of.

[NfNitLoop]

I just ran into this issue with Option<Error + Send> when trying to impl Error::cause().

Arnavion points out on IRC that this seems to be working now for Box, though:

Arnavion | Box<T + Send> does seem to be assignable to Box<T>   https://is.gd/eMP3En
Arnavion | but Option is a problem, yes

[Mark-Simulacrum]

Not sure what was meant by Option, since Option<Error + Send> is unsized so doesn't really apply; either way, I'm going to close this -- we can pursue Option in a separate issue if needed.