What do you call static methods in Rust?

help
1

Technically, an "associated function" is one that's associated with a type; and a "method" is an associated function that takes a self parameter.

What do you call the kind of associated function that doesn't have a self parameter?

I'm working on revisions to the book Programming Rust and trying to decide if we should make a change. In the current edition we use the made-up term "type-associated function":

An impl block for a given type can also define functions that don't take self as an argument at all. These are still associated functions, since they're in an impl block, but they're not methods, since they don't take a self argument. To distinguish them from methods, we call them type-associated functions.

Using a made-up term is pretty terrible, but "static method" is wrong in two ways (it's neither a static nor a method; discuss) and everything else seems worse ("constructor", "non-method associated function", ...?).

So: What do you call these things in everyday conversation? Maybe we should go with that.

1 Like
2

Great. So I assume Mr. Jim Blandy already retired?

I think I only heard the term "static method" in conjunction with other programming languages, so I have currently in my book the phrase

Rust allows associating functions directly with structs, enums, and traits using impl (implementation) blocks. These associated functions come in two main forms: methods and associated functions (often called “static methods” in other languages).

Actually I am not sure if this is fully correct -- I will watch this thread to see if my text is wrong, thanks.

2 Likes
3

I think just "associated function" is fine. for example, the documentation for Box::into_raw() has paragraph like this:

Note: this is an associated function, which means that you have to call it as Box::into_raw(b) instead of b.into_raw(). This is so that there is no conflict with a method on the inner type.

4 Likes
4

Associated functions whose first parameter is named self are called methods

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

I don't have a term for "associated functions without a self parameter"; but since I almost always refer to methods as methods, if I hear someone say associated function I assume they're talking about one with a self parameter - otherwise why not just say method?

So in conclusion, +1 vote for "associated function", even though technically that also includes methods

4 Likes
5

I use them for abstraction.

I don't know if it's good code but it's a way to hide global elements from other crates.

thread_local! {
    static WEBSOCKET: WebSocket = SignallingChannel::init().unwrap();

    static OFFER_CHANNEL: (Sender<Signal>, Receiver<Signal>) = async_channel::unbounded();
    static ANSWER_CHANNEL: (Sender<Signal>, Receiver<Signal>) = async_channel::unbounded();
    static ICE_CANDIDATE_CHANNEL: (Sender<Signal>, Receiver<Signal>) = async_channel::unbounded();
}

struct SignallingChannel {}

impl SignallingChannel {
    fn is_ready() -> bool {
        if WEBSOCKET.with(|websocket| websocket.ready_state()) == 1 {
            true
        } else {
            false
        }
    }
}

// there are bunch of this kind of functions I have. They access thread local statics.
6

I call them "type-associated functions", or "associated function" if the context makes it clear it's not associated to anything else like a trait. It wouldn't shock me if someone used "static method", since it's quite intuitive from several other languages, but it's less precise.

PS: Programming Rust is a great book! It sets an example in didacticism, and it's good to hear a next edition is in the works.

2 Likes
7

Great. So I assume Mr. Jim Blandy already retired?

Not at all—he's working on it too!

Leonora Tindall is back for the third edition too. It's a big revision. We track all the work in GitHub and we've closed about two hundred issues so far. About half of the chapters are finished.

5 Likes
8

For lack of a better term, I call them “non-methods” — when I need to, which is rare.

5 Likes
9

I would have said "non-method", too, as a qualifier for such associated functions.

I think it's fine to have ambiguity in the terminology, since the syntax is really unambiguous. You never have to reason about "is there an implicit this pointer"? or "is there dynamic function call overhead" or things like that.

Also, all methods still permit being called like non-methods with the Type::function(self_arg, other_args, …)-style syntax, anyway!

And with the right context "associated function" itself can be fine, like in the Box::into_raw docs linked above.

That's a bit like saying "this is an FnOnce-closure" when describing closure capturing rules/principles, even when technically/logically you're trying to express "non-FnMut" (and thus also non-Fn).

3 Likes
10

type-method and instance-method? and get rid of "associated"

11

Unless you draw a direct comparison to static functions in other languages - which would, most likely, only help a newcomer. Any term will work, as long as you keep it clear and consistent.

1 Like
12

If you need pure function which works on related data then you can use static methods (pure function is not a term which belongs to programming, it is belongs to mathematic and this means that you get same output for same input always). For example we have a Balance struct which stores value and type. You can write a convert() static function.


enum BalanceType {
  Wei,
  Gwei,
  Eth
}

struct Balance {
  amount: u64,
  balance_type: BalanceType
}

impl Balance {
  pub fn convert_eth(amount: u64, target_balance_type: BalanceType) -> f64 {
    match target_balance_type {
      BalanceType::Wei => amount / 1_000_000,
      BalanceType::Gei => amount / 1_000,
      BalanceType::Eth => amount,
    }
  }

  pub fn get_as_eth(&self) -> f64 {
    Self::convert_eth(self.amount, BalanceType::Eth)
  }
}

I didn't test the code, just wrote to here, some errors could be happen but I think this example explains the purpose.

13

I think it actually comes from philosophy, meaning free of empirical elements. Since then, it's been widely used in logic, mathematics, and software engineering for decades because the meaning is very similar. It's quite safe to use it in that context. :slight_smile:

I remember indeed hearing the difference between pure and impure functions when I learned Pascal, too long ago to mention.

Pure functions can be static methods, but static method doesn't mean pure function, though, because it could have side effects.

1 Like
14

Everybody haven't information which you have. Also I didn't say that "static functions can only be pure". Mostly they are pure but this isn't mandatory (at least I saw that).

15

"Non-method associated function".

95% of the time though just "associated function" is adequate. Almost anything interesting to say about non-method associated functions (NMAFs?) is equally true of methods, and it's usually clear from context when non-method functions are under consideration, so it's rare to need the qualification.

1 Like