Project

General

Profile

Feature #17097

`map_min`, `map_max`

Added by sawa (Tsuyoshi Sawada) 6 days ago. Updated 5 days ago.

Status:
Open
Priority:
Normal
Assignee:
-
Target version:
-
[ruby-core:99418]

Description

min, min_by, max, max_by return the element that leads to the minimum or the maximum value, but I think it is as, or even more, frequent that we are interested in the minimum or the maximum value itself rather than the element. For example, to get the length of the longest string in an array, we do:

%w[aa b cccc dd].max_by(&:length).length # => 4
%w[aa b cccc dd].map(&:length).max # => 4

I propose to have methods that return the minimum or the maximum value. Temporarily calling them map_min, map_max, they should work like this:

%w[aa b cccc dd].map_max(&:length) # => 4

map_min, map_max are implementation-centered names, so perhaps better names should replace them, just like yield_self was replaced by then.

Updated by nobu (Nobuyoshi Nakada) 6 days ago

Then we'll need map_ versions for all Enumerable methods.

#2

Updated by sawa (Tsuyoshi Sawada) 6 days ago

  • Description updated (diff)
#3

Updated by sawa (Tsuyoshi Sawada) 6 days ago

  • Description updated (diff)

Updated by greggzst (Grzegorz Jakubiak) 6 days ago

nobu (Nobuyoshi Nakada) wrote in #note-1:

Then we'll need map_ versions for all Enumerable methods.

Exactly, I don't see any good use case in that apart from being lazy and just using one method call. It seems to me that this kind of proposal is too much. I mean there are more pressing issues or features of the language that the team has to focus on instead of dealing with proposals like map_tally or whatever.

Updated by Eregon (Benoit Daloze) 6 days ago

I actually regularly wanted such functionality, but min_by/max_by do not return the result of the block but the element (which makes sense).
And .map {}.min/max works but is inefficient by generating an intermediate Array.

Maybe we should add some keyword argument to min_by/max_by?

Updated by Eregon (Benoit Daloze) 6 days ago

To put in context, consider that the expression might be much longer than .length.
Then repeating it is not elegant and is duplicated code.

Updated by marcandre (Marc-Andre Lafortune) 5 days ago

nobu (Nobuyoshi Nakada) is right, we're not going to add map_ for everything.

Eregon (Benoit Daloze) wrote in #note-6:

Then repeating it is not elegant and is duplicated code.

I don't see why there would be repetition.

Just do enum.map { very_long_expression }.max...

Please benchmark the time it takes to generate the intermediate array. My guess is that it's typically negligible.

Updated by sawa (Tsuyoshi Sawada) 5 days ago

I do not understand why the proposal has to be extended to all other Enumerable methods.

My point is semantic. I do not see that there are significantly more use cases where I am interested in the element that is related to the min/max value but am not interested in the min/max value than the use cases of the converse.

Also available in: Atom PDF