Move PyAnyMethods::downcast to Bound smart pointer?

[davidhewitt]

Just testing out the new 0.21 beta in pythonize, and it turns out that using obj.downcast_into() on PyAnyMethods for Bound<T> where T isn't PyAny is slightly cumbersome because the self receiver means accessing the method via deref doesn't work.

Instead using .into_any().downcast_into() chain is necessary.

Moving PyAnyMethods::downcast_into to be on Bound<T> instead would avoid the .into_any() call. This is a rare case, and the drawback would be extra generic code bloat by having all the .downcast() implementations for many different Bound<T> types.

Overall I didn't feel strongly and felt like this could be up for discussion. I think we could add this in 0.22 if we don't make a decision for 0.21.

[adamreichold]

the drawback would be extra generic code bloat by having all the .downcast() implementations for many different Bound types.

We would still see an increase in LLVM lines, but I guess this could still forward to a non-generic implementation and be #[inline(always)] itself to be compiled away as completely as possible (actually already from the MIR now that we have a MIR inliner IIRC). So I would not worry about that too much if it can measurably improve library ergonomics.