Method resolution may be finding the blanket identity impl impl<T> From<T> for T { ... } and generating an error, rather than continuing through method resolution to find the deref impl. I've had issues similar to that before, but it's hard to tell without the error message.
The trait `From<DF>` is not implemented for `Header<'_>`
When I go ahead and implement From<&'a DF> for Header<'a> I don't need to deref df, but still need to (&df).into(). This seems like a "second" and redundant implementation. I'm happy to keep having to deref it manually in this particular scenario.
The benefit of Deref seems to end with a single lookup. I can get to inner but Rust won't type the inner value to lookup a trait from there?
So with df.into() it first looks for a method into(self: DF), and it finds that DF implements Into<T> for some T (if nothing else, itself) and stops the search.
You were wanting it to find into(self: &DataFrame), i.e. the &*Ty case, and that's the first thing it looks for when you do (&*df).into().
The latter works because the method resolution mentioned above continues on until the &*Ty case without finding any other header methods for the preceding potential receiver types.
The code samples were helpful. I like how you chose to define a header method on DF to create the header.
When defining methods for DF (the parent), is there a convention in Rust to avoid depending on the DF implementation of Deref? (in which case I would use self.inner instead of self to access the inner DataFrame)?