Hash/Array/etc#dig? method are too strict regarding its key type

[bcardiff]

Extracted from #7569

The following examples works currently

h = {"a" => {"b" => [10, 20, 30]}}
h.dig? "a", "b"              # => [10, 20, 30]
h.dig? "a", "x", 0, "d", "e" # => nil
h.dig? "a", "x", 5, "d", "e" # => nil

But this does not

h.dig? "a", "b", "c", "d", "e" # => compile time error

Since the value returned by h.dig? "a", "b" responds to dig? but there is no dig? definition that can handle a String index.

The lack of that definition also prevents the following to work:

h = {"a" => {"b" => [10, 20, 30], "c" => { "d" => { "e" => 40 }}}}
h.dig? "a", "c", "d", "e" # => compile time error

[asterite]

I think that's fine. Why passing a string where an int is expected to silently give nil?

Also, I can't see how this can be implemented without having something like responds_to?(:[], String).

[bew]

Hash#dig?:

  def dig?(key : K, *subkeys)
    if (value = self[key]?) && value.responds_to?(:dig?)
      value.dig?(*subkeys)
    end
  end

The problem lies in value.responds_to?(:dig) which returns true, even if the types doesn't match, a workaround would be to loosen the types, but a better fix would be #2549 I think.

[asterite]

Hm, this works:

h = {"a" => {"b" => "hello world"}}

h.dig?("a", "b", "c", "d", "e") # => nil

I guess dig? is not type-safe at all. So yeah, if we want that, the only way to implement it (I think) is with #2549

[bcardiff]

I think we want dig? to never raise (and always compile).
We can have dig to raise and not always compile.