From: "austin (Austin Ziegler) via ruby-core" Date: 2023-07-31T14:22:17+00:00 Subject: [ruby-core:114320] [Ruby master Feature#19787] Add Enumerable#uniq_map, Enumerable::Lazy#uniq_map, Array#uniq_map and Array#uniq_map! 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/ ______________________________________________ ruby-core mailing list -- ruby-core@ml.ruby-lang.org To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org ruby-core info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-core.ml.ruby-lang.org/