▲ 36 ▼ "Useless syntax sugar": Numbered block parameters in Ruby (zverok.space) submitted 2 years ago by PythOnRails@programming.dev to c/programming@programming.dev 20 comments fedilink hide all child comments
[–] twelvefloatinghands@lemmy.world 3 points 2 years ago (4 children) Damn, I wish rust had that permalink fedilink source hideshow 8 child comments replies: [–] colonial@lemmy.world 12 points 2 years 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™. permalink fedilink source parent hideshow 4 child comments replies: [–] jendrik@discuss.tchncs.de 4 points 2 years ago (1 child) Except when Type::Method takes a reference, then it doesn't just work permalink fedilink source parent hideshow 2 child comments replies: [–] colonial@lemmy.world -1 points 2 years ago* (last edited 2 years 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. permalink fedilink source parent [–] vidarh@lemmy.stad.social 1 point 2 years ago* (last edited 2 years ago) In the case of your example we'd do .map(&:unwrap) in Ruby (if unwrap was a method we'd actually want to call) Notably, these are not the cases _1 and _2 etc are for. They are there for the cases that are not structurally "call this method on the single argument to the block" e.g. .map{ _1 + _2 } or .map { x.foo(_1) } (_1 is reasonable, because iterating over an enumerable sequence makes it obvious what it is; _1 and _2 combined is often reasonable, because e.g. if we iterate over a key, value enumerable, such as what you get from enumerating a Hash, it's obvious what you get; if you find yourself using _3 or above, you're turning to the dark side and should rethink your entire life) permalink fedilink source parent [–] TheCee@programming.dev 10 points 2 years ago I'm glad it doesnt. permalink fedilink source parent [–] paperplane@lemmy.world 3 points 2 years ago Swift does, though using the dollar sign rather than underscores permalink fedilink source parent [–] Anders429@programming.dev 1 point 2 years ago I sincerely doubt Rust would ever add something like this. permalink fedilink source parent
[–] colonial@lemmy.world 12 points 2 years 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™. permalink fedilink source parent hideshow 4 child comments replies: [–] jendrik@discuss.tchncs.de 4 points 2 years ago (1 child) Except when Type::Method takes a reference, then it doesn't just work permalink fedilink source parent hideshow 2 child comments replies: [–] colonial@lemmy.world -1 points 2 years ago* (last edited 2 years 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. permalink fedilink source parent [–] vidarh@lemmy.stad.social 1 point 2 years ago* (last edited 2 years ago) In the case of your example we'd do .map(&:unwrap) in Ruby (if unwrap was a method we'd actually want to call) Notably, these are not the cases _1 and _2 etc are for. They are there for the cases that are not structurally "call this method on the single argument to the block" e.g. .map{ _1 + _2 } or .map { x.foo(_1) } (_1 is reasonable, because iterating over an enumerable sequence makes it obvious what it is; _1 and _2 combined is often reasonable, because e.g. if we iterate over a key, value enumerable, such as what you get from enumerating a Hash, it's obvious what you get; if you find yourself using _3 or above, you're turning to the dark side and should rethink your entire life) permalink fedilink source parent
[–] jendrik@discuss.tchncs.de 4 points 2 years ago (1 child) Except when Type::Method takes a reference, then it doesn't just work permalink fedilink source parent hideshow 2 child comments replies: [–] colonial@lemmy.world -1 points 2 years ago* (last edited 2 years 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. permalink fedilink source parent
[–] colonial@lemmy.world -1 points 2 years ago* (last edited 2 years 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. permalink fedilink source parent
[–] vidarh@lemmy.stad.social 1 point 2 years ago* (last edited 2 years ago) In the case of your example we'd do .map(&:unwrap) in Ruby (if unwrap was a method we'd actually want to call) Notably, these are not the cases _1 and _2 etc are for. They are there for the cases that are not structurally "call this method on the single argument to the block" e.g. .map{ _1 + _2 } or .map { x.foo(_1) } (_1 is reasonable, because iterating over an enumerable sequence makes it obvious what it is; _1 and _2 combined is often reasonable, because e.g. if we iterate over a key, value enumerable, such as what you get from enumerating a Hash, it's obvious what you get; if you find yourself using _3 or above, you're turning to the dark side and should rethink your entire life) permalink fedilink source parent
[–] TheCee@programming.dev 10 points 2 years ago I'm glad it doesnt. permalink fedilink source parent
[–] paperplane@lemmy.world 3 points 2 years ago Swift does, though using the dollar sign rather than underscores permalink fedilink source parent
[–] Anders429@programming.dev 1 point 2 years ago I sincerely doubt Rust would ever add something like this. permalink fedilink source parent