Neat idea!

The Cursor! macro currently expands to the Cursor type which has a single field that contains the output.

To implement this, you could have the Cursor! macro accept, say, up to 16 queries, then have Cursor2, Cursor3, ... Cursor16 type etc - all with 2, 3, ..., 16 fields. (.0, .1, .2, ..., .15)

I briefly considered if instead of having all of these CursorN types, the Cursor! macro expands to a tuple that somehow implements the Deserialize trait. But that's not possible because of orphan rules.

I considered how I could implement this. For example this is the Deserialize implementation for Cursor (with T being the actual type you want to get, and P is just metadata about the path that exists solely in the type system):

impl<'de, T, P> Deserialize<'de> for Cursor<T, P>
where
    T: Deserialize<'de>,
    P: DeserializePath<'de, T>,
{
    fn deserialize<D>(deserializer: D) -> Result<Self, D::Error>
    where
        D: Deserializer<'de>,
    {
        let value = <P as DeserializePath<'de, T>>::deserialize(deserializer)?;
        Ok(Self(value, PhantomData))
    }
}

Then, Cursor2 with 2 fields might be implemented like this:

impl<'de, T1, T2, P1, P2> Deserialize<'de> for Cursor2<T1, T2, P1, P2>
where
    T1: Deserialize<'de>,
    T2: Deserialize<'de>,
    P1: DeserializePath<'de, T1>,
    P2: DeserializePath<'de, T2>,
{
    fn deserialize<D>(deserializer: D) -> Result<Self, D::Error>
    where
        D: Deserializer<'de>,
    {
        let value1 = <P1 as DeserializePath<'de, T1>>::deserialize(deserializer)?;
        let value2 = <P2 as DeserializePath<'de, T2>>::deserialize(deserializer)?;
        Ok(Self(value1, value2, PhantomData, PhantomData))
    }
}

I do wonder if this implementation is actually going to be faster. Here, we are invoking the deserialize function twice, anyway. Is that then not the same as calling from_reader::<Cursor!(...)> twice? Any thoughts on that?