Issue #11762 has been updated by Colin Kelley.


> I'd guess, like Colin, that returning nil is probably the best. Makes debugging harder when writing new code, but makes backward compatibility easier, since old code using dig wouldn't bomb if the data layout changes in the future.

Yes, exactly. If we have to wrap the navigation with `rescue`, then we don't really need `dig` at all; we always had the option to wrap our collection navigating code with a rescue.

~~~
hash = {a: []}
result = hash.dig(:a, :b) rescue nil
~~~

would be about the same as what we can do now without `dig`:

~~~
result = hash[:a][:b] rescue nil
~~~

I think we need `dig` to navigate into a nested collection whose layout is not certain and return `nil` if the value wasn't found.  This is essentially extending the `Hash#[]` behavior to nested collections that are so common now.

----------------------------------------
Bug #11762: Array#dig can raise TypeError: no implicit conversion of Symbol/String into Integer
https://bugs.ruby-lang.org/issues/11762#change-55331

* Author: Colin Kelley
* Status: Open
* Priority: Normal
* Assignee: Yukihiro Matsumoto
* ruby -v: 2.3.0-preview1
* Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN, 2.2: UNKNOWN
----------------------------------------
If you try to `dig` in an Array using a symbol or string, a `TypeError` exception will be raised:

irb> ['zero', 'one', 'two'].dig(:first)
TypeError: no implicit conversion of Symbol into Integer
    from (irb):1:in `dig'
    from (irb):1

I think it should return `nil` in this case.  The most typical use case for `dig` is to dig through parsed JSON and either find the result we expected or else `nil`.  Wouldn't it defeat the purpose of `dig` if we had to wrap calls to it in a `rescue` to handle the case that an Array was present where we expected a Hash?

Can we clarify the desired behavior for this case, then update the documentation and tests to reflect that?



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