From: "alexeymuranov (Alexey Muranov)" <redmine@...> Date: 2013-09-05T04:17:08+09:00 Subject: [ruby-core:57019] [ruby-trunk - Feature #7292] Enumerable#to_h Issue #7292 has been updated by alexeymuranov (Alexey Muranov). =begin Matz, it was just a reminder about (({#assoc})) and (({#rassoc})), sorry if it was redundant. IMO, they serve a similar purpose to (({#to_h})): they allow to use an ((*array of two-element arrays*)) as a storage where selection "by key" or "by value" is possible. I think, if (({#assoc})) and (({#to_h})) were introduced simultaneously, the following would have given identical results: [[:a, 1], [:a, 2]].assoc(:a) # => [:a, 1] [[:a, 1], [:a, 2]].to_h.assoc(:a) # => [:a, 2] with any of the suggested above implementations I probably didn't used "consistent" correctly, not in mathematical sense. I meant something closer to "natural": that as many operations or ((*diagrams*)) ((*commute*)) as possible. That is, when appropriate, the result of (({x.foo.bar})) should be the same as that of (({x.bar})), or, if (({#foo})) applies some "essential" transformation to (({x})), but there exists an operation (({#baz})) applicable to (({x.bar})) that is a "counterpart" of (({#foo})), then it would be nice if (({x.foo.bar})) was identical with (({x.bar.baz})), unless it makes sense to have them different. Here are the corresponding "commuting diagrams" (not exactly, but this gives the idea): x -- #foo --> x.foo \ | #bar #bar \ | J V x.bar = x.foo.bar x --------- #foo ---------> x.foo | | #bar #bar | | V V x.bar -- #baz --> x.bar.baz = x.foo.bar I do not insist, i am just trying to explain what i meant. =end ---------------------------------------- Feature #7292: Enumerable#to_h https://bugs.ruby-lang.org/issues/7292#change-41617 Author: marcandre (Marc-Andre Lafortune) Status: Open Priority: Normal Assignee: marcandre (Marc-Andre Lafortune) Category: core Target version: next minor Now that #to_h is the official method for explicit conversion to Hash, we should also add Enumerable#to_h: Returns a hash for the yielded key-value pairs. [[:name, 'Joe Smith'], [:age, 42]].to_h # => {name: 'Joe Smith', age: 42} With the Ruby tradition of succint documentation I suggest the documentation talk about key-value pairs and there is no need to be explicit about the uninteresting cases like: (1..3).to_h # => {1 => nil, 2 => nil, 3 => nil} [[1, 2], [1, 3]].to_h # => {1 => 3} [[1, 2], []].to_h # => {1 => 2, nil => nil} I see some reactions of people reading about the upcoming 2.0 release like this one: http://globaldev.co.uk/2012/11/ruby-2-0-0-preview-features/#dsq-comment-body-700242476 -- http://bugs.ruby-lang.org/