this post was submitted on 11 Oct 2023
0 points (NaN% liked)
Programming
17318 readers
90 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities [email protected]
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
It wouldn't be as relevant, since passing a function or method instead of a closure is much easier in Rust - you can just name it, while Ruby requires you to use the
method
method.So instead of
.map(|res| res.unwrap())
you can do.map(Result::unwrap)
and it'll Just Work™.Except when Type::Method takes a reference, then it doesn't just work
Well, that's to be expected - the implementation of
map
expects a function that takes ownership of its inputs, so you get a type mismatch.If you really want to golf things, you can tack your own
map_ref
(and friends) onto theIterator
trait. It's not very useful - the output can't reference the input - but it's possible!I imagine you could possibly extend this to a combinator that returns a tuple of
(Input, ref_map'd output)
to get around that limitation, although I can't think of any cases where that would actually be useful.