You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
The text was updated successfully, but these errors were encountered:
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).
Scenario:
format
all over the place with those types.Display
for[T]
.Expected:
Display
for[T]
, just as I can forT
, 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 ofDisplay
.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 likecombine
, which naturally ends up taking sub-slices of inputs.The text was updated successfully, but these errors were encountered: