5 ms·
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.
by trevor-e 4y 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.
- deleted 4y ago[deleted]
- Gigachad 4y agoI'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.
- lilyball 4y ago`x.zip(y)` evaluates to `Option<(i32, i32)>`
- deleted 4y ago[deleted]
- FridgeSeal 4y agoOptions 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>.
- stouset 4y agoYou 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.
- trevor-e 4y agoMy 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.