Issue #21858 has been updated by Dan0042 (Daniel DeLorme). matz (Yukihiro Matsumoto) wrote in #note-9:
The consistency argument is noted, but I have reservations about introducing `to_h` into `Hash()`.
Unlike `to_ary`/`to_a` or `to_int`/`to_i`, `to_h` has an unusual property: it is defined on Enumerable and Array, but whether it succeeds depends on the *content* rather than the *type* of the object. For example, `[[1,2]].to_h` succeeds but `[1,2,3].to_h` raises — both are Array.
`to_hash` serves as a reliable signal that an object "is a Hash", while `to_h` means "can be converted, maybe". Feeding `Hash()` with a method that may raise depending on runtime content makes the function less predictable, not more.
I understand the desire for consistency, but in this case I think the asymmetry with `Integer()`/`Array()` is intentional by accident and worth preserving deliberately.
Matz.
---------------------------------------- Feature #21858: `Kernel#Hash` considers `to_h` too https://bugs.ruby-lang.org/issues/21858#change-116750 * 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/