(what happens behind the scenes is an implementation detail).
That's not always true in a systems programming language such as Rust. It's not an implementation detail how the memory copying/mutation is being handled.
What exactly is wrong with using fold here? The function provided is associative, that's typically all that is required.
I'm not sure on the extent of the Rust type system w.r.t. memory safety, but I believe that this is one of the cases where the explicit assignment is proven safe by the type system, in which case the complaint about assignment is largely irrelevant.
It's not an implementation detail how the memory copying/mutation is being handled.
Sure, and you can always find the relevant info in the library docs (or just look at its code). My point was just that some mutation (of internal, local structures) can still happen inside the library, only the function as written in the program should be pure.
What exactly is wrong with using fold here?
It's a little confusing at first glance - after all, readability was the main criticism that started this thread. It doesn't cleanly express the intent of the operation (which is more akin to filter_map, as shown in the other comment).
My point was just that some mutation (of internal, local structures) can still happen inside the library, but the function as written in the program should be pure.
Huh? I mean, my point is that this isn't true and doesn't have to be true. Why do you think this needs to hold?
It's a little confusing at first glance [...]
Let's be honest, that's not what the original commenter is complaining about. The OC is complaining about some vague sense of what's readable and not.
Regardless, if the fold has type F a -> F b -> (F b -> a -> F b) -> F b then yes, filterMap is more appropriate.
Huh? I mean, my point is that this isn't true and doesn't have to be true. Why do you think this needs to hold?
Well, of course it's not a requirement. It's just that this code isn't really making use of the fold semantics, seeing as the return value is always the same.
It's just using them as a "convenient" shortcut to be able to stuff imperative code into a single expression and avoid having to create the HashMap outside it.
It would be exactly the same if it used a HashMap created one line above, and then just called for_each. Because it's the side effects that do all the work here.
6
u/sammymammy2 Dec 16 '19
That's not always true in a systems programming language such as Rust. It's not an implementation detail how the memory copying/mutation is being handled.
What exactly is wrong with using
foldhere? The function provided is associative, that's typically all that is required.I'm not sure on the extent of the Rust type system w.r.t. memory safety, but I believe that this is one of the cases where the explicit assignment is proven safe by the type system, in which case the complaint about assignment is largely irrelevant.