Rubyists are already using 'map' to build and return an array, so it should be obvious that 'map_to(object)' can be used to build and return an object.

Given that 'each' and 'each_with_index' return the original array, I feel that the 'each_with_object' method name is slightly counterintuitive. 'map_to' might not be 100% semantically correct, but it's obvious that it will return something other than the original array.

Many people (myself included) were using inject({}) {|hash, el| ... ; hash } instead of 'each_with_object', partly because of ignorance, but also because 'each_with_object' is so long. 'map_to' is the same length as inject, and means that you don't have to return the object at the end of the block.

I just searched each_with_object in GitHub and aside from some specs testing each_with_object all real-use cases I could see after navigating though several pages of the results were ".each_with_object({})...":

That is why I think we should have a .hash_map method instead of another generic one:

double = numbers.hash_map{|h, n| h[n] = n * 2 }

Better to read than

double = numbers.each_with_object({}){|n, h| h[n] = n * 2 }

But other than that, I don't really think map_to is a bad name for the generic case (I'm replacing the arguments order of the block since it makes more sense to me instead of using it as an alias to each_with_object):

double = numbers.map_to({}){|h, n| h[n] = n * 2 }

I read this as "map numbers to hash" which makes lots of sense to me. Much more than each_with_object. Which only seems to be used with hashes by the way...

=begin
But the crux of the problem is simply that #each_with_object has a name that it is too long, which greatly deters usage. I know I am loathe to use it even when it would be useful for this simple reason. And that has also has a lot to do with the fact that the last word of the method's name, "_object", is complete redundant. Of course it is a object! Ruby is an OOPL! So just shortening it to #each_with alone would make a big difference.

Beyond that, one might argue the block parameters should be in the opposite order to align with #inject, but that isn't at all important. More significant would be to default the argument to an empty hash, since that would be the most common case. I think that's a good idea so the common case can be more concise. But in doing that, it makes more sense to call the method #map_with and have it return the object.

I agree that object is a redundant suffix and that map_with is probably a better description than eachwith or each_with_object.

But it makes sense to me that each_with_object should yield(item, object) because of the name of the method. I do agree that the order of the arguments isn't very important but I would prefer to have the returning value to become first as it seems more natural to me and it also aligns well with inject like you said.

Now, what I'm not comfortable with is using map_with with {} as the default argument. I agree this is the commonest case, this is not the issue. The problem is that this doesn't read well for someone trying to understand the code:

So, if it was my decision to design the language I would probably deprecate each_with_object in favor of map_with, I'd replace the order of the arguments in the block and would also create another method:

def hash_map(&block)
map_with({}, &block)
end

Instead of hash_map I'd also support the idea of using to_h as suggested by someone a while back:

The common thread here is that people want a hash conversion in an enumerable chain, where it feels fluent and natural, rather than wrapping the result with Hash[] which makes the code read backward. #each_with_object is wonderful, but verbose for this use.

Ruby has the idea of an association already: a key and value paired together. It's used by Array#assoc to look up a value from a list of pairs and by Hash#assoc to return a key/value pair. Building up a mapping of key/value pairs is associating keys with values. So consider Enumerable#associate which builds a mapping by associating keys with values:

The common thread here is that people want a hash conversion in an enumerable chain, where it feels fluent and natural, rather than wrapping the result with Hash[] which makes the code read backward. #each_with_object is wonderful, but verbose for this use.

Ruby has the idea of an association already: a key and value paired together. It's used by Array#assoc to look up a value from a list of pairs and by Hash#assoc to return a key/value pair. Building up a mapping of key/value pairs is associating keys with values. So consider Enumerable#associate which builds a mapping by associating keys with values:

Exactly.

Here's the secret plan I propose:
1) Let's convince Matz about Enumerable#to_h by adding your +1 to #7292.
2) When that's done, and only when that's done, we can convince Matz that 'associate' is the right name for a nifty method that associates keys with values. See my 1 min slide in #4151 . I believe my proposal agrees with yours and it also handles collisions and the special case of Hash#associate.
Note that we should start with Enumerable#to_h. If we have it, then we can see it's probably best if [].associate (with no block) returns an enumerator, not a hash.
3) After that, we can see if we can come up with a general 'categorize' that could replace map{ [k, v] }.to_h as well as more complex nested cases.

I'd also propose you move the discussion of these features from here (a rejected request about an alias of map_with_object!) to the right issues.

#4151 proposes an Enumerable#categorize API, but it's complex and hard to understand its behavior at a glance.#7292 proposes an Enumerable#to_h == Hash[...] API, but I don't think of association/pairing as explicit coercion, so #to_h feels misfit.

Associate is a simple verb with unsurprising results. It doesn't introduce ambiguous "map" naming. You associate an enumerable of keys with yielded values.

Associate is a simple verb with unsurprising results. It doesn't
introduce ambiguous "map" naming. You associate an enumerable of keys with
yielded values.
...
Apologies for hijacking this rejected ticket with a different proposal. I
will open a new feature request if anyone is positive on this usage.

Yep, I'll add my +1 to this feature request. I think #associate is a great
name and would be a very useful method.

I like the "associate" name but I prefer the implementation to be like the hash_map described above. I have lots of situations where the element of the Enumerable is not the key of the resulting hash. Your suggestions sounds inefficient to me for this case: