Return a vec / array in crossroads

[hellow554]

I want to return a vec of items with crossroads, here's my code:

let mut cr = Crossroads::new();

let iface_token = cr.register(
    "name",
    |b: &mut IfaceBuilder<()>| {
        b.method("read", (), ("logs",), move |ctx, _, ()| {
            Ok(vec![(3_u32, 4_i64, 5_u8)])
        });
    },
);

This doesn't compile because of:

error[E0277]: the trait bound `Vec<(u32, i64, u8)>: ArgAll` is not satisfied
   --> src/dbus.rs:26:45
    |
26  |               b.method("read", (), ("logs",), move |ctx, _, ()| {
    |  _______________------________________________^
    | |               |
    | |               required by a bound introduced by this call
27  | |                 Ok(vec![(3_u32, 4_i64, 5_u8)])
28  | |             });
    | |_____________^ the trait `ArgAll` is not implemented for `Vec<(u32, i64, u8)>`
    |
    = help: the following other types implement trait `ArgAll`:
              ()
              (A, B)
              (A, B, C)
              (A, B, C, D)
              (A, B, C, D, E)
              (A, B, C, D, E, F)
              (A, B, C, D, E, F, G)
              (A, B, C, D, E, F, G, H)
            and 6 others
note: required by a bound in `IfaceBuilder::<T>::method`
   --> /home/marcel/.cargo/registry/src/git.luolix.top-1ecc6299db9ec823/dbus-crossroads-0.5.0/src/ifacedesc.rs:521:47
    |
521 |     where IA: arg::ArgAll + arg::ReadAll, OA: arg::ArgAll + arg::AppendAll,
    |                                               ^^^^^^^^^^^ required by this bound in `IfaceBuilder::<T>::method`

error[E0277]: the trait bound `Vec<(u32, i64, u8)>: AppendAll` is not satisfied
   --> src/dbus.rs:26:45
    |
26  |               b.method("read", (), ("logs",), move |ctx, _, ()| {
    |  _______________------________________________^
    | |               |
    | |               required by a bound introduced by this call
27  | |                 Ok(vec![(3_u32, 4_i64, 5_u8)])
28  | |             });
    | |_____________^ the trait `AppendAll` is not implemented for `Vec<(u32, i64, u8)>`
    |
    = help: the following other types implement trait `AppendAll`:
              ()
              (A, B)
              (A, B, C)
              (A, B, C, D)
              (A, B, C, D, E)
              (A, B, C, D, E, F)
              (A, B, C, D, E, F, G)
              (A, B, C, D, E, F, G, H)
            and 15 others
note: required by a bound in `IfaceBuilder::<T>::method`
   --> /home/marcel/.cargo/registry/src/git.luolix.top-1ecc6299db9ec823/dbus-crossroads-0.5.0/src/ifacedesc.rs:521:61
    |
521 |     where IA: arg::ArgAll + arg::ReadAll, OA: arg::ArgAll + arg::AppendAll,
    |                                                             ^^^^^^^^^^^^^^ required by this bound in `IfaceBuilder::<T>::method`

how can I return multiple values inside of a method? Should I open a PR that implements ArgAll and AppendAll for Vec<T> where T: ArgAll + AppendAll?

[hellow554]

I'm really not sure, if this is the right way, but it works? :)

struct MyVec<T>(Vec<T>);
impl<T> ArgAll for MyVec<T>
where
    T: Arg,
{
    type strs = (&'static str,);

    fn strs_sig<F: FnMut(&'static str, dbus::Signature<'static>)>(a: Self::strs, mut f: F) {
        f(a.0, Signature::make::<Vec<T>>());
    }
}

impl<T> AppendAll for MyVec<T>
where
    T: Arg + Append,
{
    fn append(&self, ia: &mut dbus::arg::IterAppend) {
        ia.append(Array::new(&self.0));
    }
}

Still waiting for a proper answer though

[hellow554]

Okay, my bad, but this is somewhat inconvenient...

The correct solution would be:

Ok((vec![(3_u32, 4_i64, 5_u8)],))

so a 1 sized tuple instead of the vec directly. Is there a reason for this, or just a technical decision?

[diwic]

This is the correct answer. In D-Bus, methods take a list of arguments and return another list of arguments. Because arguments can have different types, they are modeled in Rust as tuples, no matter if it's the zero tuple, a tuple of one, a tuple of two, and so on.

I don't remember if there also was a technical problem with coercing anything that is not a tuple into a tuple of one, like overlapping trait implementations or that some edge case would be ambiguous or something else, or if it just was a decision and I never tried anything else.