From: recursive.madman@...
Date: 2014-12-31T19:35:39+00:00
Subject: [ruby-core:67257] [ruby-trunk - Feature #10683] [Open] fix inconsistent behavior of Kernel.Hash()

Issue #10683 has been reported by Recursive Madman.

----------------------------------------
Feature #10683: fix inconsistent behavior of Kernel.Hash()
https://bugs.ruby-lang.org/issues/10683

* Author: Recursive Madman
* Status: Open
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
----------------------------------------
I find the way the global function `Hash` (aka `Kernel.Hash`) works a bit confusing.

To illustrate:

```ruby
Hash(nil) #=> {}  (1)
Hash({})  #=> {}  (2)
Hash([])  #=> {}  (3)
# but
Hash([[1,2]]) #! TypeError (4)
```

Case (1) and (2) make perfect sense to me (calling `Hash(var)` when `var` is an optional argument defaulting to `nil` will always give a (possibly empty) Hash or a TypeError, which is very useful).
Case (3) however seems inconsistent, since (4) doesn't work.

To contrast this with the respective `String` function:

```ruby
String([])  #=> "[]"
String('')  #=> ""
String({})  #=> "{}"
String(0)   #=> "0"
String(nil) #=> ""
```

it seems that calling `String(obj)` is equivalent to calling `obj.to_s`.

Thus I would assume `Hash(obj)` being equivalent to calling `obj.to_h`.

It is not though (calling `to_h` on `[[1,2]]` gives `{1=>2}`, while using `Hash()` raises a `TypeError`).

I propose to do **one** of the following changes:
* either remove the special handling of `[]`, such that only `nil` or a `Hash` are valid values to be passed to `Hash()`, or
* change `Hash()` to call `to_h` on it's argument, when the argument is neither `nil` nor a `Hash`.




-- 
https://bugs.ruby-lang.org/