In rust that will return itself, which allows you to chain method calls, if that's your style. For example, with the Timer class [1], you could write:

  someTimer.set_interval(1000).start();

instead of writing:

  someTimer.set_interval(1000);
  someTimer.start();

[1]: https://github.com/cybergeek94/kiss-ui/blob/master/src/timer...

All the other comments are right, and in Rust this is referred to as "the builder pattern", and is used quite commonly. Here's a guidelines link[0] describing it in more detail.

[0]: https://aturon.github.io/ownership/builders.html

Note that those guidelines are outdated, superseded by https://github.com/rust-lang/rust-guidelines

Note that _those_ guidelines are outdated, superseded by https://github.com/rust-lang/rust/tree/master/src/doc/style and http://doc.rust-lang.org/style/

Note that we haven't linked to those publicly all that much yet, as there's so much TODO in them still.

Ahh, Rust. :)

There's a part in the book about the builder pattern: http://doc.rust-lang.org/stable/book/method-syntax.html#buil...

Thanks for the updated links! I totally committed the sin of linking to the first thing from google that looked approximately right.

It's at least partially our fault. (And basically entirely so, really :) ) Gotta get on that rel=canonical at least. Old search results are a big problem :/

This would be to enable method chaining so you can do stuff like:

    dialog.set_title("blah").set_size_pixels(100, 100);

(note syntax may be out - I am not a Rust expert...)

Couldn't one write a chain macro instead ? That way you don't have to rely on the library to return self.

    chain!(dialog, set_title("blah"), set_size_piels(100, 100));

Okay, yes, you could do that, but the library itself provides this as its idiomatic way of doing things.

The macro is a better solution, since you can't rely on every library doing this kind of thing.

Why wouldn't I want to do

dialog.set_title("blah");

dialog.set_size_piels(100, 100);

on two lines?

Different strokes. It's a common idiom in JavaScript, for instance. You can do multiple lines if you want, nothing stops you.

Because functional programming.

To expand a bit: Sometimes, instead of thinking about nouns all the time, you want to think about verbs. Instead of saying "mutate this noun by applying verb1" and then "mutate this noun by applying verb2" etc, you are creating a new verb. The new verb is "verb1 then verb2 then...." And then when you have the verb defined, you apply it to your object.

I feel APIs like that are a bit misleading in Rust in many cases, though, since they're also mutating the original. In Rust, if you want to perform a functional update like that you should take the type by move, but almost everyone just uses mutating APIs because mutation is explicit in the signature anyway. I think that's one of the biggest differences in practice between Rust and other MLs (with which it otherwise has a lot in common): in most MLs, mutation is treated as a last resort, while in Rust it's extremely common because it (generally) doesn't have nonlocal effects.