What is an argument in a function?

pub fn some_fun<T>(&mut self, arg_a: T, arg_b: T){}

How many arguments this function accepts?

The function takes 1 type (T) template argument. In the following examples T with be (), assuming that some_fun is implemented for X.

  • If it's bound, it takes 2 arguments.
    struct S;
    let mut x = S;
    x.some_fun((), ());
  • If it's unbound, it takes 3 arguments.
    struct S;
    let mut x = S;
    X::some_fun(&mut x, (), ());

I wasn't aware that you can actually invoke function with first param &self as an unbound function.
Thanks for the answer.

1 Like

Methods in Rust are little more than a syntactic sugar for functions that also keeps in mind the receiver. That's why methods are also called associated functions.

On its own that term may or may not mean something to you, but it becomes clearer and more consistent when taking into account e.g. associated constants, or in the case of traits, associated types.


I was under the impression that "associated functions" means functions from an impl block that specifically do not take self.

Sometimes you have to.

That is orthogonal, it's an associated fn either way, static fn or no.

That's the terminology other languages use. I think Rust has decided to use its own terminology.
Within the context of Rust, a method is a function that's defined in an impl block and takes self as a parameter. An associated function is a function defined in an impl block and doesn't take self as a paremeter.

The following snippets from the book corroborate this:
Method Syntax
Associated Functions
Fully Qualified Syntax (paragraph above listing 19-19)
When dealing with smart pointers the standard library doesn't want to define methods on their type that will clash with the methods of the inner type (via Deref coercion). The standard library uses this same terminology here:

Admittedly, std::rc::Rc and Arc#deref-behavior say:

To avoid name clashes with T 's methods, the methods of Rc<T> itself are associated functions

Taking this literally seems to contradict the earlier links, but I think they're called methods here because it helps with the wording.

1 Like

Maybe we should make "selfless functions" a term of art :smirk:


Either way, that's just semantics in the literary sense of the word. You're missing the larger point, which is that there's a consistency between various associated items.

Methods are a specific kind of associated function, and folks tend to use the more specific name, so it can feel like it means they're separate, whereas they're really a more specific form. Does that make sense?


In what way are methods more specific form of an associated function? Example would be great.

It's the definition. A "method" is an associated function that has a self parameter.

struct Foo;

impl Foo {
    // an associated function
    fn foo() {
        // body goes here

    // an associated function, has a self parameter, therefore is also a method.
    fn bar(&self) {

This applies for any self parameter; &self, &mut self, and self are all syntax sugar for various forms of self: Self.

1 Like

Yes, but you've said that "methods" are more specific form of a function. From the given examples I don't see which one is more and which one is less specific. Could you clarify that please.

All methods are associated functions, but not all associated functions are methods.

Ah, I get it. But surely this is very... How shall I put it... OK, got it. This is very rust specific. There is no fast and hard rules (outside of rust) what is a function and what is a method. Those definitions are very often used interchangeably.

In my experience, each programming language has its own terminology as to what functions and methods are. Rust just happens to have gone with functions as the most general case, associated functions as functions attached to types, and methods as associated functions that take a self parameter.


Sure, it neither warms me nor makes me cold. Just like I've said: It is very rust specific, that is this particular classification, but it is neither particularly good nor bad.

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.