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/