Allow slices to be used in field

[GuillaumeGomez]

No description provided.

[rust-highfive]

r? @Mark-Simulacrum

(rust_highfive has picked a reviewer for you, use r? to override)

[Mark-Simulacrum]

I'm not sure that these changes are backwards-compatible, and also seem to go against the reason for using a trait object (making the output code small). Why are we making this change? What specifically does it allow; what are the tradeoffs?

Overall, I don't think I'm the best reviewer for this, maybe r? @dtolnay

Looks like Travis failed, too.

[dtolnay]

For the gstreamer-sys change, would it work to use &&self.v[..] instead of &self.v as &[i32]? Playground

[GuillaumeGomez]

@dtolnay: it would indeed, but sounds more like a trick. :-/ At least, with this, it'd be more "logical" (if we could combine trait objects, it'd be even simpler).

@Mark-Simulacrum: It fails because a test supposed to fail is now passing. Also, I have no issue having a debate over this PR. It was just a fix for a specific situation after all.

[dtolnay]

I would prefer to stick with &&self.v[..] for now and follow up with the real fix which is allowing dynamically sized types to be trait objects. That may allow &self.v as &[i32] without this change. All of std::fmt uses trait objects extensively to help compile times and executable sizes.

[GuillaumeGomez]

That'd be awesome! Any follow-up issue for dynamically sized trait objects?

[dtolnay]

Hmm, it may be rust-lang/rfcs#2035 with something like &(Debug + ?Sized) but I'm not sure.

[dtolnay]

Another possible fix would be a deref coercion where &DynamicallySizedType coerces to &TraitObject by implicitly doing & twice.

use std::fmt::Debug;

fn f(_trait_object: &Debug) {}

fn main() {
    f("str"); // does not compile today. would coerce to &&str
    f(&[1][..]); // does not compile today. would coerce to &&[{integer}]
}

That would also make &self.v as &[i32] work without changing the signature of DebugStruct::field. I filed rust-lang/rfcs#2239 to follow up.