Tuple references

1

Hi! I wanted to double-check whether I’m missing something obvious here.

Consider the following simplified code:

fn main() {
    let a: A = /* ... */;
    let b: B = /* ... */;
    let c: C = /* ... */;
    g(&a, &b, &c);
    h(a, b, c);
}

To make some of the code (including the signatures of g and h) a bit cleaner, I thought about introducing a type alias: type Data = (A, B, C), so that g would take &Data and h would take Data . But it seems to me that changing g's input to &(a,b,c) would lead to unnecessary cloning because a tuple (a,b,c) has to be constructed?

This feels like something that should be natural in Rust, but I can’t see a slick way to express it. Am I overlooking an obvious approach?

2

You need another type for references:

type DataRef<'a, 'b, 'c> = (&'a A, &'b B, &'c C);
3

you are right that a tuple (a, b, c) needs to be constructed, but there's no Clone here, rust will never insert .clone() calls implicitly.

and it will compile only if the types of a, b, and c were all Copy (or if they would not be used later so they could be moved)

note, this is not only happenning for g(&(a, b, c)) where you took a reference, it would also happen for h((a, b, c)) where you pass the tuple by-value: you still needs to construct the tuple.

however, when they are all Copy types, I don't think it would make any real difference here: for simple cases, it would probably generate the same code thanks to the optimizer, and for non-trivial computations, the overhead of the potential extra copy of a couple of bytes is insignificant compared to the heavy computation?

anyways, I don't understand why you wanted to change the funciton's parameter type this way in the first place. it makes little difference from fn (A, B, C) to fn ((A, B, C)). if you needs more type safety, then create a proper type (as opposed to an alias to a tuple), in which case you can also turn the function into a method.

4

Does it make sense for a, b, and c to be members of a struct with methods g and h? The only difference between that and the tuple approach is that you don't have to name the tuple type.

2 Likes
5

You can also use a generic type. You can then use it either in free functions or with associated functions (aka. methods):

6

This is, in some sense, exactly what I'm trying to avoid as it would again lead to unnecessary cloning? Edit: Oh you mean that the functions become methods? That might work well in this particular situation, thanks!

7

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.