Allow crates defining type T to implement external traits for [T]

[rnewman]

Scenario:

• A third-party library defines types that work with slices of other libraries' types.
• It uses format all over the place with those types.
• There is no derived implementation of Display for [T].

Expected:

• I can implement Display for [T], just as I can for T, allowing third-party libraries to call Display-requiring methods with both slices and individual values.

Actual:

• [T] is a type that isn't defined in my crate. Display is a trait that isn't defined in my crate. The compiler refuses to allow me to implement it.

Example playground:

https://is.gd/lLsx57https://is.gd/lLsx57

The stated workaround (from IRC; thanks talchas) is to define some kind of wrapper type, MySlice, that I own. This wrapper contains a reference to the real slice, and implements every necessary trait as a passthrough to the slice. That fixes the ownership of the type, allowing implementation of Display.

This workaround presupposes that it's possible to get the third-party library to accept a MySlice wherever it calls arbitrary traits, rather than it getting a &[T] out of something else. I haven't assessed whether that's feasible for something like combine, which naturally ends up taking sub-slices of inputs.

[oli-obk]

This probably belongs into the rfc repo: https://github.com/rust-lang/rfcs/issues/

[Mark-Simulacrum]

Please open an issue on the RFCs repo or post a pre-RFC to internals.rust-lang.org. This is a fairly major change to the language (large implications if small implementation, or at least, I think it should be small).