this post was submitted on 11 Oct 2023
0 points (NaN% liked)

Programming

17318 readers
73 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
[–] [email protected] 0 points 1 year ago (3 children)

Damn, I wish rust had that

[–] [email protected] 0 points 1 year ago (2 children)

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™.

[–] [email protected] 0 points 1 year ago (1 children)

Except when Type::Method takes a reference, then it doesn't just work

[–] [email protected] -1 points 1 year ago* (last edited 1 year ago)

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 the Iterator 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.