Update dict hashability check, once the language spec is updated

[Quarz0]

According to the spec, The meaning of membership varies by the type of the second operand: the members of a list or tuple are its elements; the members of a dict are its keys; the members of a string are all its substrings..

This implies that to use the in operator with dict as a right operand, the left operand has to be a hashable type (like what python does, giving an error if it's not hashable). Also, it'd make no meaning to search for a key that cannot be hashed. Thus the following should give an error rather than False:

[] in {}                 #  False
range(10) in dict()      #  False
{} in {}                 #  False

[brandjon]

The spec wording actually seems to indicate that [] in {} is allowed.

The in operator reports whether its first operand is a member of its second operand
[...]
the members of a dict are its keys

Since [] is not a member of {}, the answer is False.

That said, it's clearly undecided as per bazelbuild/starlark#65. Leaving this issue open to track it from Bazel's side.

[sgowroji]

Hi there! We're doing a clean up of old issues and will be closing this one. Please reopen if you’d like to discuss anything further. We’ll respond as soon as we have the bandwidth/resources to do so.