> 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.
OK, but if you avoided calling non-functional patterns part of functional
programming, you would avoid invoking the topic of "what constitutes
functional programming" altogether.
OK, but if you avoided disputing the definition of a word the author explicitly said was irrelevant, you would avoid invoking the topic of "what constitutes functional programming" altogether.
> In computer science, functional programming is a programming paradigm—a style of building the structure and elements of computer programs—that treats computation as the evaluation of mathematical functions and avoids changing-state and mutable data.
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.
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":
Yeah that is one way of doing it, but I'm not sure how practically useful it actually is; many functional languages do allow for mutation and/or side effects too. Often in a controlled way, of course, but then again, so does Rust. That said, I wouldn't argue that Rust is a functional language exactly, mostly that I find essentialist FP definitions to be lacking, like most essentialist definitions.
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 :)
Most people perceive structs and fields as an aspect of object-oriented programming, but you probably wouldn't write about them under the heading of "Object-oriented programming".
Maybe change the title to "Functional Language Idioms"?
`FnMut` just means that the iterator methods don't artificially restrict the user-supplied closures. `map` itself doesn't become impure just because you can map `|x| { counter += x; x+1 }` over your list if you really want to.
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.
Certainly functional programming is not making the data containers to fulfil
a separately defined interface. This comes from OOP paradigm (its form that is
implemented in most languages).
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.
I did, at least the relevant parts of your question. And it still stands that
you missed my point that you just created a contention point fully knowing
that it is useless contention (your quoted remark from the chapter prooves
both that you knew it will be problematic and that you didn't need it
there).
No OO style interfaces here, Ierator and IntoIterator are traits, which are more akin to a type class from Haskell than an interface as seen in OO languages
> 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.