Note that in my example the type information flows from the variable to picking which generic method that is called, which is reversed information flow of what I would call the most trivial case - when the variable gets its type from the method that was called. (This is trivial: let x = 1i32;)
> C++ doesn't support it
How exactly is it different?
#include <iostream>
#include <vector>
int main() {
std::vector<int> v1 = {1,2,3};
auto it = v1.begin();
std::vector v2 (it + 1, it + 2);
for (auto i: v2) { std::cout << i << ' '; }
} let samples: Vec<_> = iterator.collect();
std::vector v2 (v1.begin() + 1, v1.begin() + 2);
The Rust example is incomplete and its RHS by the time it gets to `.collect()` within the context of `iterator` has to be bound to a particular type of the context via `impl Iterator for <MyContext>`. This is pretty much the same thing as template argument deduction for class templates in C++17 [1][2], and in C++20 it got extended to generic concepts and constraints [3]:
#include <numeric>
#include <vector>
#include <iostream>
#include <concepts>
template <typename T>
requires std::integral<T> || std::floating_point<T>
constexpr auto avg(std::vector<T> const &v) {
auto sum = std::accumulate(v.begin(), v.end(), 0.0);
return sum / v.size();
}
int main() {
std::vector v { 1, 2, 3 };
std::cout << avg(v) << std::endl;
}
[1] https://en.cppreference.com/w/cpp/language/template_argument...
[2] https://devblogs.microsoft.com/cppblog/how-to-use-class-temp...
That's because the entire haskell ecosystem would have to be rewritten which seems insurmountable.
The point is that the borrow checker forces you to program in a fundamentally different style than idiomatic Haskell.
(Rust has your C-like run of the mill function references too. People should emphasize those more, because differently from closures, those work very well.)
In contrast, function pointers are very rarely used.
Are they equivalently nice in every way to closures in Haskell? Of course not. But I think your comment is swinging way too far in the opposite direction.
I came to Rust from Haskell (among other languages). I was a little confused by closures, but I attributed that to the fact that I started writing Rust before 1.0 when closures were far far far less convenient than they are today. (This is back when there were 'proc' closures.) Now I find them extremely natural.
Everything else pretty much falls into place.
The other thing that was added since you've looked at Rust is that you can return unboxed closures because Rust has gained the ability to express anonymous types directly by naming a trait it implements:
fn adder(x: i32) -> impl Fn(i32) -> i32 {
move |y| y + x
}
fn main() {
let add2 = adder(2);
assert_eq!(7, add2(5));
assert_eq!(10, add2(8));
} fn adder(x: i32) -> impl Fn(i32) -> impl Fn(i32) -> i32 {
move |y| move |z| y + x + z
}
fn adder(x: i32) -> impl Fn(i32) -> Box<dyn Fn(i32) -> i32> {
move |y| Box::new(move |z| y + x + z)
}
fn main() {
let add23 = adder(2)(3);
assert_eq!(10, add23(5));
assert_eq!(13, add23(8));
}
[1] https://hirrolot.github.io/posts/rust-is-hard-or-the-misery-...
Now if you said, "Rust has some rough points at the intersection of generics, closures and async programming," I'd say that's absolutely true!
This might rather confirm my point, since engineers using a specific programming language quite often have a contorted picture of how code in other languages is written, as they become more and more acquainted with their main tool. If we compare Rust closures with those of ML languages, it becomes pretty clear how natural closures are in ML and tricky in Rust.
Not quite a sensation either to anybody who happened to use closures in a typical Rust code, which, apparently, happens to have quite a lot of generics and async!
> This might rather confirm my point
It might, but it doesn't, because I don't only use Rust. Notice also how you've moved the goalposts from "fundamentally broken" (sensationalist drivel) to "how natural closures are in ML and tricky in Rust" (a not unreasonable opinion with lots of room to disagree on the degree of "natural" and "tricky").
Generics and closures work just fine:
use std::ops::Add;
fn adder<T: Copy + Add<Output=T> + 'static>(x: T) -> impl Fn(T) -> Box<dyn Fn(T) -> T> {
move |y| Box::new(move |z| y + x + z)
}
fn main() {
let add23 = adder(2)(3);
assert_eq!(10, add23(5));
assert_eq!(13, add23(8));
}
I haven't claimed that closures are not working, since well, they are working, but under a very limited set of circumstances. Again, I see nothing sensational, since the trickery of using closures has been discussed elsewhere.
[1] https://stackoverflow.com/questions/34814423/possible-to-def...
Of course it's generic. If you were to write the type out for the closure, it would be generic over 'T'. (Whether that type ever actually gets written out that way or not is a different matter.) As far as I can tell, what you're saying is that Rust doesn't support higher-rank polymorphism. Which is true (for types, but not for lifetimes). But that's not the same as "generics don't work with closures."
> I haven't claimed that closures are not working
You've said:
> Closures in Rust are fundamentally broken.
(which was completely unqualified and not to a "very limited set of circumstances")
and (emphasis mine)
> But I can basically demonstrate other language features that are not working with closures, such as generics
OTOH, things like parser combinators are much more ergonomic in Haskell than Rust.
Haskell has a garbage collector for a reason.
You can't program naturally with closures unless you have a garbage collector, because closures introduce cyclic references.
Also, Haskell has a type inference system that allows e.g. the IO monad to work seamlessly with the rest of the language.