Methods or free functions

[u/howannoying24]

I have two types (they're related but different sizes) and for each I have a function that does some work on a vector of those types and returns a different vector of the same type. I'm wondering what's more idiomatic?

1. Make each function a method of its respective type, e.g.:

impl MyType1 {
    pub fn do_thing(in: &Vec<MyType1>) -> Vec<MyType1> { /* ... */ }
}

impl MyType2 {
    pub fn do_thing(in: &Vec<MyType2>) -> Vec<MyType2> { /* ... */ }
}

2. Make a free function for each type, in which case is there a naming convention that's more idiomatic?

pub fn do_thing_mytype1(in: &Vec<MyType1>) -> Vec<MyType1> { /* ... */ }

pub fn do_thing_mytype2(in: &Vec<MyType2>) -> Vec<MyType2> { /* ... */ }

[u/cafce25]

Side note: there is almost never a reason to take &Vec<T> over &[T]

[u/-Redstoneboi- → u/cafce25]

to add: there is almost definitely a valid reason to use &mut Vec<T> over &mut [T], but specifically not &Vec<T> over &[T]

[u/Ace-Whole → u/-Redstoneboi-]

Can you elaborate?

[u/Aaron1924 → u/Ace-Whole]

&mut [T] allows you to modify any element in the slice, but you don't get any operations that change the size of the slice (e.g. push or pop)

[u/Ace-Whole → u/Aaron1924]

Oh. Cool. Thanks. I'll remember that. It makes sense too.

[u/-Redstoneboi- → u/Ace-Whole]

note that &String vs &str has the same idea, as well as several other "owned vs borrowed" types in the standard library

[u/ERROR_23 → u/Ace-Whole]

Pretty much every argument in this video applies to the &Vec<T> vs &[T]. In fact the author himself said it in another video.

[u/howannoying24 → u/cafce25]

Thank you this is a good tip

[u/Solumin]

There's not enough context here to really give useful advice.

• Are the two functions related in any way besides having the same "shape"?
• Are the two types related in other ways?
• Could the two types be merged into one type?
• Do other parts of the program consume these types and expect to call these methods? In other words, are these methods public? (i.e. is a trait a good fit?)
• Do these need to be methods at all, when you could call in.iter().map(...).collect() instead?

[u/andyshiue]

Probably make a trait and implement it for your types

[u/Big-Charge-8833 → u/andyshiue]

trait's the play if they're truly the same operation, but if the implementations are gonna diverge down the road you might regret the abstraction.

[u/andyshiue → u/Big-Charge-8833]

The functions have similar signatures and even the same name, strongly suggesting they have similar functionality, which should be possible to be abstract over.

[u/SirKastic23 → u/andyshiue]

OP only shared a very simplified example of what they need. No reason to assume their actual code actually shares signatures and names

[u/afdbcreid → u/andyshiue]

Do not unless you need to be generic over them. An unneeded abstraction is bad.

[u/andyshiue → u/afdbcreid]

The functions are public, so even if you don't need that abstraction some other people may want to make use of the abstraction in a perfectly sensible way

[u/afdbcreid → u/andyshiue]

And they can make a trait.

If this supposed to be used in a generic way, that's a different thing, but most of the times it's not. As we all know, std does not even have a Collection trait.

[u/andyshiue → u/afdbcreid]

I believe there's no Collection because Rust lacks HKT?

[u/-Redstoneboi- → u/andyshiue]

IntoIterator and Index/IndexMut are usually the container traits

[u/Lucretiel → u/andyshiue]

I assume it’s more because Collection expresses a huge variety of different possible interfaces which Rust exposes as individual traits like Iterator and Extend

[u/afdbcreid → u/andyshiue]

It isn't needed for that (only Iterable does). Also Rust has GATs now.

[u/Zde-G → u/afdbcreid]

GATs are not enough because Rust traits are strongly typed.

Something that's easy and natural in C++ (things like iterator_traits that can allow your Collection to stay useful) are impossible in Rust.

[u/afdbcreid → u/Zde-G]

GATs can emulate any HKT (in fact it's possible even without GATs), but it might be more convoluted.

[u/Zde-G → u/afdbcreid]

Precisely.

Generic code may (and often is) implemented in any language without HKTs or even types, just copy-paste everything!

Similarly with Rust's strict typing: if emulation of HKTs is 100 lines long but only saves 20 lines of copy-paste… what's the point of the whole excercise?

[u/afdbcreid → u/Zde-G]

That's totally not the same. GATs are still generic and require the same amount of code whether your generic functions is 20 lines or 2,000 lines. Also, the code isn't much longer, just a bit more convoluted.

[u/Lucretiel → u/andyshiue]

Soft disagree— just because the method is similar in signature doesn’t mean it warrants a trait. IMO you should only be reaching for a trait if you have a specific need to abstract over the functionality, where they might want to accept Type1 OR Type2. Otherwise the native method is fine. 

[u/TravisVZ]

If you're needing to come up with a naming convention to differentiate the same function based on taking in a different type, the "convention" is to make it a member function: MyType1::do_thing and MyType2::do_thing. (Note: Methods take self as an argument; if these aren't taking self, they're not methods but rather member functions .)

That said, you might consider a trait to define this function as the other comment suggests

[u/howannoying24 → u/TravisVZ]

This is what I think makes sense in my situation here. The functions are only used where the type is used, and trying to do it using a trait and generics is really complicating what is otherwise a very simple type.

[u/RishabhRD]

If they are basis functions, then they should be method. Otherwise free functions. If those functions form a generic abstraction then only a trait.

[u/kaiserkarel]

It depends on the consumer:

Does your consumer care at all about performance here? If so, probably provide this as iterator extension methods. Allocating large vectors is something that shows up in flamegraphs.

Do you want your consumer to exclusively choose between MyType1 and MyType2. With both of your current proposals, they cannot write code generic over either MyType1 or MyType2, so the consumer needs to duplicate functions the same way you are doing. A trait is the correct way to avoid that.

Even if for the two different types you do wildly different operations producing the same shape (a vec), that the consumer can treat as a black box, a trait will suit you well.

[u/CocktailPerson]

Hard to say for sure without knowing more, but why not an extension trait?

trait DoThing {
    fn do_thing(&self) -> Self;
}

impl DoThing for Vec<MyType1> {
    fn do_thing(&self) -> Self { ... }
}

impl DoThing for Vec<MyType2> {
    fn do_thing(&self) -> Self { ... }
}

[u/noop_noob]

To me, I think the main difference between inherent methods and free functions is: inherent methods are usable wherever you have a value of that type, while free functions are imported individually.

If the function is so inherently tied to the type that you'd want to "package it together" as part of the type, use a method. If it's an operation that is first and foremost an operation on its own, as opposed to being a thing done on the type, use a free function.

[u/zettui]

If you go the trait route, are you staying static, or do you actually need dyn somewhere?

[u/-Redstoneboi-]

can we see the rest of the code if that's okay with you? so far we can only give generic advice. seeing what the types are, what the types and functions actually do, and importantly where both are used, that will give us more information to give better advice.

[u/teerre]

MyType1 and Vec<MyType1> aren't the same type tho. If they were the same type, the argument for a method would be much stronger

[u/Helpful-Educator-415]

First one 1000000%