Issue #21858 has been updated by Dan0042 (Daniel DeLorme). matz (Yukihiro Matsumoto) wrote in #note-9:
Feeding `Hash()` with a method that may raise depending on runtime content makes the function less predictable, not more.
It's important to note that this is **already the case**; if you pass it an array, `Hash()` may raise depending on runtime content: ```ruby Hash([]) #=> {} Hash([1,2]) #TypeError Hash([[1,2]]) #TypeError #vs [].to_h #=> {} [1,2].to_h #TypeError [[1,2]].to_h #=> {1=>2} ``` Given that `Hash([])` returns `{}`, I find it highly confusing that `Hash([[1,2]])` is an error. If something can be converted to a hash I would expect `Hash()` do to just that. Using #to_h would make this more consistent, but really this is not so much a matter of consistency but more a matter of usefulness. It would be fine to keep the current behavior if there is a use case for `Hash([[1,2]])` being an error, but really I can't think of any reason anyone would want this. ---------------------------------------- Feature #21858: `Kernel#Hash` considers `to_h` too https://bugs.ruby-lang.org/issues/21858#change-116754 * Author: ccmywish (Aoran Zeng) * Status: Feedback ---------------------------------------- 1. `Kernel#Integer` uses `to_int` first and `to_i` second 2. `Kernel#Array` uses `to_ary` first and `to_a` second 3. `Kernel#Hash` only uses `to_hash` I don't quite understand why there is a need for differential treatment here. I admit that maybe the only benefit of considering `to_h` secondly is that it enables multiple APIs to maintain consistency. -- https://bugs.ruby-lang.org/