Issue #19787 has been updated by austin (Austin Ziegler). joshuay03 (Joshua Young) wrote in #note-4:
Is `.map { ... }.uniq` such a very frequent idiom?
I work on a Rails codebase and it's most commonly used to iterate through foreign keys / associated records and get the unique values (quite often in tests). That's the only real frequent use case I've come across, but I would say that outside of that, it's not an uncommon chaining pattern either.
Wouldn’t it make more sense, then, to do `uniq { … }.map { … }`? Yes, there’s a *small* bit of extra code, but it means that you’re in most cases going to be performing *less work* than either `.map { … }.uniq` or `uniq_map { … }`, because you’re reducing to unique instances before mapping them. If your computations are complex enough that they should be done before `#uniq`, I would bypass the need for `#uniq` altogether and use `#reduce`.
`.uniq_map { ... }` is not as concise as `.map { ... }.uniq`.
I'm a bit mixed on this point. I see where you're coming from, and I think the same argument can be made about `#flat_map` and `#filter_map`. But it follows a similar naming pattern where the alternative chained methods are in the name, so I personally feel like it's it's equally as concise?
I would also like to point out that with `#uniq_map`, you don't need to read all the way to `.uniq` before inferring the output. This might help when the body of the `#map` is quite complex, but you could argue that this is a code quality / style problem...
The `#map` block being complex is even more of an argument for reversing the flow or using `#reduce`.
``` some_array.map do |item| if some_condition some_method(item) else some_other_method(item) end end.uniq
# vs
some_array.uniq_map do |item| if some_condition some_method(item) else some_other_method(item) end end ```
Both of these could be shorter if you use brace blocks (which should be preferred when **using** the output of a method like `#map`). ```ruby some_array.map { some_condition ? some_method(_1) : some_other_method(_1) }.uniq ``` From a reduced operations perspective, `#reduce` is going to be faster than most anything else, and there are multiple options for the operation, but `Set` is likely to be your best case: ```ruby some_array.reduce(Set.new) { _2.add(some_condition ? some_method(_2) : some_other_method(_2)) }.to_a ``` Uniquely mapped in one pass, although I think still less efficient than `uniq {}.map {}` because you have to map the items before determining that they are unique (via `Set#add`). One could implement this without `Set`, but that would require a bit more work: ```ruby some_array.reduce({}) { v = some_condition ? some_method(_2) : some_other_method(_2) _1[v] = true unless _1.key?(v) _1 }.keys These are both *slightly* less efficient than your C code because I don’t believe that there’s a way to preallocate a Hash size from Ruby (there have been proposals, but I don’t believe any have been accepted).
Scala doesn't seem to provide `uniqMap`.
Sorry, this is the first Ruby issue I've created or being involved with, so I'm not sure why this was pointed out. Is this a usual consideration for new features?
When trying to add a functional shorthand, it is common to compare it against other functional languages to see if it or a close synonym is commonly used because many people working with functional operations find it useful to have such a shorthand. So, not unusual.
Considering the above, I think the motivation is too weak to provide `uniq_map`.
Your points are very valid, and I appreciate the response. What is the usual process for deciding on whether or not to accept a feature?
Consensus-building mostly. I don’t think that `#uniq_map` is a good addition because it is *only* sugar over `.map {}.uniq` and cannot sugar over `.map {}.uniq {}`, and I think that — with the exception of the intermediate hash-size preallocation — `#reduce` or `.uniq {}.map {}` will be as or more efficient than `#uniq_map`. I don’t have benchmarks, though. ---------------------------------------- Feature #19787: Add Enumerable#uniq_map, Enumerable::Lazy#uniq_map, Array#uniq_map and Array#uniq_map! https://bugs.ruby-lang.org/issues/19787#change-104020 * Author: joshuay03 (Joshua Young) * Status: Open * Priority: Normal ---------------------------------------- I would like to propose a collection of new methods, `Enumerable#uniq_map`, `Enumerable::Lazy#uniq_map`, `Array#uniq_map` and `Array#uniq_map!`. TL;DR: It's a drop in replacement for `.map { ... }.uniq`, with (hopefully) better performance. I've quite often had to map over an array and get its unique elements. It occurred to me when doing so recently that Ruby doesn't have a short form method for doing that, similar to how `.flat_map { ... }` replaces `.map { ... }.flatten` and `.filter_map { ... }` replaces `.map { ... }.compact` (with minor differences). I think these new methods could be beneficial both in terms of better performance and writing more succinct code. I've got a draft PR up with some initial benchmarks in the description: https://github.com/ruby/ruby/pull/8140. -- https://bugs.ruby-lang.org/