Functional Language Features in Rust – Iterators and Closures
rust-lang.github.io
rust-lang.github.io
let add_one = |x| x + 1;
let five = add_one(4);
Answered my question a few paragraphs down. Kudos.
Is it possible to write a generic closure? i.e something that would add 1 to any numeric type.
To answer your last question, not yet. There was an RFC for this, but it was recently postponed; closures rely heavily on traits and we are in the process of re-doing the internals of the trait system. If I remember the reason correctly.
I absolutely love it when a blog post, talk, or docs like these do that.
Especially during talks. Often the speaker will say something and it will immediately pop up questions in my mind which I really really want to ask but of course I should wait till the end. And then they answer it in the next slide. Perfect :)
Incidentally, I just finished the build system stuff today to get the new book shipped on doc.rust-lang.org; that slates it to land in Rust 1.18. It will still be a draft, but this is one more step towards it being finished.
I've never had any issues with it.
It would be nice if we could use ? on the Option
returned from next, but ? only works with Result
values currently. Even if we could use ? on Option
like we can on Result, the value we would get would
be borrowed, and we want to move the String from
the iterator into Config.
let search = match args.next() {
Some(arg) => arg,
None => return Err("Didn't get a search string"),
};
let search = args.next().ok_or("Didn't get a search string")?;
It might actually be a nice segue into a page on the combinators of Option and Result, since functional-style Rust seems to benefit from liberal use of them.
> Umm...If I don't quote the entire code snippet, I'll end up with just the indented lines being quoted...the joys of HN formatting.
This allows for responsive formatting on different screen sizes, and is especially beneficial for mobile users.
> We're going to sidestep the issue of what, exactly, functional programming is or is not, and instead show off some features of Rust that are similar to features in many languages referred to as functional.
Many people think of "programming with higher order functions" to be a feature of functional languages, and that may be wrong, but it's also okay. The goal is to teach the stuff, not worry about what exacty "functional" means.
from https://en.wikipedia.org/wiki/Functional_programming
I totally agree that neither iterators nor 2/3s of closures are "functional programming". That's fine, though, because I really enjoy the sane way that it all was done.
If you check out
https://doc.rust-lang.org/std/iter/trait.Iterator.html
and search for `FnMut`, you see that most of the iterator methods are side-effectful. That is cool and fun and very useful, but it isn't functional programming.
Edit. The term you are probably looking for (guessing) is "higher-order programming":
That said, you're right that "higher order" is a better description of these features, but my counter would be that most people perceive higher order programming as an aspect of functional programming, bringing it full circle again :)
Maybe change the title to "Functional Language Idioms"?
That's a good suggestion, I'll think about it, thanks :)
I think it's fair to say that iterator methods are typically used as combinators to build computations out of pure functions to avoid having to manage mutable state.
And then, what specifically does "functional programming" mean to you that makes implementing an interface a feature from functional paradigm?
But this all misses the point of my comment. If you knew it would invoke the unnecessary discussion to call the iterator "functional feature" (as the quoted comment signifies), you should have rephrased the title of the chapter in the first place, rendering the disclaimer unnecessary.