Hacker News Reader

Comment by adamch | Hacker News Reader

You can't abstract over it in the same way that you can in Haskell, because you have to manage ownership. You can't abstract away ownership as easily, because the language is designed to make you care about ownership.

I write Rust code for my day job, and I frequently use map/reduce/filter. IMO if I can write all my collection-processing code using primitives like that, it's got first-class functions.

View on HN

It's not about "abstracting away" ownership, it's about being polymorphic over it. I want to keep the distinction between Fn, FnOnce, and FnMut. But I want to be able to write a `compose` function that works on all three, returning the correct type in each case. That's not taking away from my ability to manage ownership, it's letting me abstract over it.

You could do the polymorphic return with an enumeration. But those are distinct types with very different semantics: you can’t just say “it returns a function that you can call once or maybe a function you can call more than once. Shrug”.

I believe they're asking for "this function returns a function of the same type (Fn/FnMut/FnOnce) as its first argument, but with different arguments. A generic way to write something like `fn bind<T, F: Fn(T,...) >(f: F, arg: T) -> Fn(...)`

> But those are distinct types with very different semantics: you can’t just say “it returns a function that you can call once or maybe a function you can call more than once. Shrug”.

Right, that's why I want parametricity i.e. HKT. String and Int are different types with very different semantics, you can't just say "it returns a String or maybe an Int, shrug", but it's very useful to be able to write generic code and datastructures (e.g. collections) that work for String and Int.

Reply on news.ycombinator.com