Hacker News new | ask | show | jobs
by trevor-e 1255 days ago
Yea the latter code is unreadable to me and feels obfuscated, like the author is trying to force functional programming where it doesn't belong.
2 comments

You might choose to believe that, but `Option` and `Result` are practically purpose-built in Rust to work extremely well with functional approaches.

And doing so greatly increases the likelihood that the compiler can produce perfectly optimal code around them.

My issue was with the `zip()` usage. For lists I know that it will stop short once one of the lists has run out of items, but I haven't seen it used this way to combine optional values. I'm assuming it only produces a result if all of the elements passed in are non-null (based on the prior code) but it still seems too clever IMO. IDK, maybe this is a common pattern I'm unaware of.
I've done a non trivial amount of functional programming and know what zip and map do but I can't off the top of my head work out how that example works.
`x.zip(y)` evaluates to `Option<(i32, i32)>`
Options can be mapped/zipped/“iterated” over (traversed might be a better word?).

So in this case it’s using that fact to form a tuple of non-null values whenever the option is not null, and then acting on that. I think it’s kinda neat, but I wouldn’t personally use zip in this case, I’d have gone with map or and_then depending on whether the output of my operation is T or Option<T>.