add IntoPyObjectRef derive macro

[Icxolu]

From #4041 (comment)

Introduces the IntoPyObjectRef derive macro to implement IntoPyObject for a reference to the derived type. It pretty much uses the same code gen as the ordinary IntoPyObject derive macro. I have moved the relevant branches up to the root function, to avoid threading the reference condition through the whole machinery. We really only need to adjust the ident itself, generic bounds, transparent types and introduce the named lifetime, the body works by inference and does not need changes between the two.

I added this to the hygiene, roundtrip and ui tests. I skipped hygiene IntoPyObject4 because it would need IntoPyObject for &&Bound which we currently don't have, not sure where we want to draw the line.

Closes #4041 🎉

[davidhewitt]

Great, awesome to see that this just works out! 🎉

Just a final thought - is RefIntoPyObject or IntoPyObjectRef better? I quite like it starting with Into, which would suggest we stick with IntoPyObjectRef, but the order RefIntoPyObject feels more accurate to me as a description. 🤔

[davidhewitt]

Also, thank you for just seeing my brief musing and running with it to build something which is hopefully quite convenient for users!

[davidhewitt]

I added this to the hygiene, roundtrip and ui tests. I skipped hygiene IntoPyObject4 because it would need IntoPyObject for &&Bound which we currently don't have, not sure where we want to draw the line.

I feel like there might be a way where we could use specialization inside the macro to achieve that, but I'm also happy if we defer that for a follow-up for simplicity's sake.

(i.e. because &Bound is Copy it feels to me like we might not need to support &&Bound, but it might be that there's thorny edge cases...)

[Icxolu]

Just a final thought - is RefIntoPyObject or IntoPyObjectRef better? I quite like it starting with Into, which would suggest we stick with IntoPyObjectRef, but the order RefIntoPyObject feels more accurate to me as a description. 🤔

Personally I prefer IntoPyObjectRef. (It reads nicer to me) I think the name is still descriptive enough. If there is need we can always extend the documentation a bit to make.

I feel like there might be a way where we could use specialization inside the macro to achieve that, but I'm also happy if we defer that for a follow-up for simplicity's sake.

I guess we probably could special case here, but this applies to pretty much to all types. So if this would store &String (for whatever reason), IntoPyObjectRef would have &&String which we don't supply an impl for. Special casing a few (of our) types is not really a solution to the problem.

Maybe we can provide this blanket impl?

impl<'a, 'py, T> IntoPyObject<'py> for &&'a T
where
    &'a T: IntoPyObject<'py>,
{
    type Target = <&'a T as IntoPyObject<'py>>::Target;
    type Output = <&'a T as IntoPyObject<'py>>::Output;
    type Error = <&'a T as IntoPyObject<'py>>::Error;

    #[inline]
    fn into_pyobject(self, py: Python<'py>) -> Result<Self::Output, Self::Error> {
        (*self).into_pyobject(py)
    }
}

[davidhewitt]

That blanket seems like a very good idea, I can't think of a reason why a user would ever want a different implementation for &&T if they've implemented for &T.

Let's add that blanket before 0.23 as a follow up, maybe I can PR that quickly this morning in an hour or so...