NilClass#to_h would be useful. Especially for Enumerable types, it's common convention to return an empty container of that type, so that you can chain things together.

The proliferation of nil is often considered a code smell, there's tons of cases where converting nils into values that still mean 'nothing' but have some amount of meaning is useful. See Avdi's talk at RailsConf about Confident Code, for example: http://avdi.org/talks/confident-code-railsconf-2011/

It should be created and implemented for NilClass, Hash, Enumerable, Struct, OpenStruct.

It would also pave the way for more generic hash splat if the proposal is accepted (see )

The implementation proposed by Suraj Kurapati can not be accepted in its current form, though. In particular, there should be no Object/Kernel#to_h (like there is no Object#to_a/to_i), and Hash#to_h should return a new copy for subclasses (like to_a, to_s).

I realize that Matz doesn't like Enumerable#to_h because there is no perfect "natural" mapping. I feel like any choice here is better than no choice. I think it would be fine if Enumerable#to_h was equivalent to the key-value pair form of Hash[enum.to_a], but I'll agree with any other sane definition, as long as it's simple.

For more involved cases, I'm still hoping for Enumerable#associate/categorize.

"Repeating myself, unlike other classes in the table, Hash does not have "natural" conversion from set of values, so that I don't think it's worth provide to_h method."

What does that even mean?

From a practical vantage, I use #to_h all the time and constantly have to define it in my projects. I just did it a few minutes ago, in fact. The need stems from polymorphic behaviour on data mappings.

def some_method(data)
data = data.to_h
# ... now I have a known data object to work with ...
end

Anything that responds to #to_h can be passed. Without that we would have to account for every possible type, which is very limiting and basically not practical.

While #to_hash could be used, as with the other conversion methods, it conveys the object is a Hash in it's very essence --not simply an object that can fashion a hash from itself regardless of how. An object that responds to #to_hash, otoh, would almost certainly respond to #[], #[]= and #each and probably #key?, #keys and #values, too. Although obviously there is no necessary set of public methods it must provide. But is a much stronger indication of the object's nature.

Another use case is simple serialization. #to_h is hand-dandy for converting representation of objects to JSON. Again, something like Contact#to_h is perfectly useful and sensible, where as Contact#to_hash just doesn't jive.

"Repeating myself, unlike other classes in the table, Hash does not have "natural" conversion from set of values, so that I don't think it's worth provide to_h method."

What does that even mean?

I see, you were referring to Enumerable#to_h and meant there is no "single definitive" method to conversion. True, and to that end, I, with the help of other developers, worked through the general permutations of these:

Or for convenience we could allow nil to respond to each, like in
Groovy:
null.each {} // or eachWithIndex - doesn't throw an exception

Why go down the road of adding this to nil instead of just relying on ||?

foo = some_method || {}
foo.each { ... }

What if some_method returned false instead of nil with this pattern? It
would must probably be some kind of bug hard to track... Unfortunately
Ruby doesn't have a similar operator that will only operate on nil objects.

I'm not saying that we should copy Groovy behavior as I still don't have
a strong opinion on this subject. But Groovy has added "each" and
"collect" to Object and not only to NullObject.
This way, it allows 10.collect{it} == [10] and null.collect{it} == [].
But on the other hand, 'abc'.collect{it} == ['a', 'b', 'c'] and I don't
like this behavior.

While I find that adding each and collect to NilClass might be valid, I
wouldn't like them to be added to Object.

In fact I would prefer to be able to use each and collect with nil
objects rather than adding a "to_h" to it if we're talking about
convenience.

I think nil.to_h is probably fine, for the same reason nil.to_a is fine,
and it would nice to have it. But, I think adding #each to NilClass is the
wrong way to go to get around being able to call #each on the return value
of some method call. If you really need to_h behaviour, I think you can go
for || before sticking #each on NilClass.

#to_hash protocol expects the object to be hash-compatible. Struct is not the case.

I'm reopening this issue, as the request is not for #to_hash but for #to_h.

I believe you are positive for Hash#to_h, Struct#to_h and OpenStruct#to_h.

You are hesitant about NilClass#to_h, and we were wondering why. I think the translation from nil to {} would be consistent with the transitions to the other basic types, like nil.to_s, nil.to_i, nil.to_f, nil.to_c, nil.to_r. It's the only one missing!