Feature #9239
closed
Array#to_h ignores flat arrays
Added by sawa (Tsuyoshi Sawada) about 11 years ago.
Updated almost 11 years ago.
Description
=begin
My understanding was that the newly introduced Array#to_h was to be equivalent to Hash.[]. But when I give a flat array, it returns an empty hash:
[:a, :b].to_h # => {}
[:a].to_h # => {}
I expected {:a => :b} for the first example, and ArgumentError: odd number of arguments for Hash for the second example, as is with Hash[]. Was it intended to be different? If so, why is that the case? Even if it is to be different, it should at least raise an error when a flat array is given.
=end
- Tracker changed from Bug to Feature
- Assignee set to matz (Yukihiro Matsumoto)
Moving to "feature", as the current documentation states that elements that are not 2-element arrays are ignored, so it is different from Hash.[]
My opinion is that the fact that Hash[1,2,3,4] # => {1 => 2, 3 => 4} is a misfeature and that this usage should not be encouraged.
On the other hand, Array#to_h could raise an error on elements that are not 2-element arrays. I argued otherwise before, but maybe that would be safer.
If [:a, :b].to_h returned {:a => :b}, then what should [[:a, :b], [:c, :d]].to_h return? {[:a, :b] => [:c, :d]} ?
marcandre (Marc-Andre Lafortune) wrote:
My opinion is that the fact that Hash[1,2,3,4] # => {1 => 2, 3 => 4} is a misfeature and that this usage should not be encouraged.
On the other hand, Array#to_h could raise an error on elements that are not 2-element arrays. I argued otherwise before, but maybe that would be safer.
I agree.
One reason I think I was wrong is that current form could encourage code like:
enum.map{|x| [x.foo, x.bar] if x.baz? }.to_h
using the fact that any nil will be ignored. I'm not sure that it's a good idea.
It would probably be safer to raise an Exception for elements that are not a key-value pair. It also satisfies fail-early principle.
Matz, what do you think?
- Category set to core
- Assignee changed from matz (Yukihiro Matsumoto) to marcandre (Marc-Andre Lafortune)
- Target version set to 2.1.0
I dont think we should commit this before 2.1, is there good reason?
Since this is a new feature, there's no risk of regression and there is no incompatibility. Committing after 2.1 could create incompatibility.
How would committing after 2.1 create incompatibility?
If we commit this feature to trunk after ruby_2_1 branch is created, then it won't be released until 2.2, right?
zzak (Zachary Scott) wrote:
How would committing after 2.1 create incompatibility?
If some rubyists write code for Ruby 2.1 using this new Arry#to_h and rely on the fact that elements that are not key value pairs are ignored, then this change in 2.2 will break their code. This is what I mean by incompatibility.
I think you should ask for permission from naruse before you commit
marcandre (Marc-Andre Lafortune),
Thanks for the patch to reflect my request, and thanks for ALREADY HAVING ASKED Naruse-san for the commit.
- Assignee changed from marcandre (Marc-Andre Lafortune) to naruse (Yui NARUSE)
- Priority changed from Normal to 6
- Status changed from Open to Rejected
As Array#to_h says and test_to_h describes, Array#to_h is different from Hash[].
The behavior is expected one.
Returns the result of interpreting ary as an array of
[key, value] pairs. Elements other than pairs of
values are ignored.
Yui, I'm wondering if you actually read the whole thread. In any case, I probably don't have to point out that Matz usually has the privilege of rejecting feature requests.
I've summarized it as #9270.
Also available in: Atom
PDF
Like0
Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0
Updated by 
Updated by 
Updated by 
Updated by 
Updated by