Hash#any?

Hash#any?, Hash#all?, and Hash#none? check whether entries in a hash satisfy a condition. These methods come from the Enumerable module, which Hash includes. They return boolean values and work with both keys and values.

These methods are a good fit when you want a yes-or-no answer about the whole hash rather than a transformed result. They keep validation code compact and they read like the question you are asking the data.

Key takeaways

• any?, all?, and none? answer boolean questions about a hash.
• They come from Enumerable, so the same ideas apply to many Ruby collections.
• Use the block form when you need to inspect both key and value.
• Use the pattern argument when you want a quick key match.
• These methods are especially handy for validation and configuration checks.

Syntax

hash.any?                          # true if hash has any truthy value
hash.any? { |(key, value)| block } # true if block returns true for any entry
hash.any?(pattern)                 # true if any key matches (Ruby 2.5+)

hash.all?                          # true for empty hashes
hash.all? { |(key, value)| block } # true if block returns true for all entries

hash.none?                         # true if hash has no truthy values
hash.none? { |(key, value)| block } # true if block returns false/nil for all entries

Parameters

Parameter	Type	Default	Description
pattern	Object	nil	Optional pattern to match keys against (Ruby 2.5+). Can be a Class, Regexp, or Range
block	Proc	nil	Optional block that receives each key-value pair as [key, value]

Examples

Without a block

When called without a block, these methods check for the existence of truthy values:

{ a: 1, b: 2 }.any?
# => true

{ a: nil, b: nil }.any?
# => false

{}.any?
# => false

{ a: nil, b: false }.none?
# => true

{ a: 1 }.all?
# => true

An empty hash returns false for any?, but true for all? and none? because there are no entries to contradict the condition. This follows the logical principle of vacuous truth, where a universal statement about an empty set is considered true by default.

With a block

The block receives each key-value pair as a two-element array:

user = { name: "Alice", age: 30, email: "alice@example.com" }

# Check if any value is a string
user.any? { |(_key, value)| value.is_a?(String) }
# => true

# Check if all values are present (not nil)
user.all? { |(_key, value)| !value.nil? }
# => true

# Check if no key starts with a specific letter
user.none? { |(key, _value)| key.to_s.start_with?("z") }
# => true

When you pass a block, each entry arrives as a two-element array where the first element is the key and the second is the value. Destructuring with |(key, value)| makes the intent clear, though Ruby 3.0+ also supports the shorthand |key, value| for blocks that expect array elements. Choose the destructuring style that matches your team’s conventions.

Checking keys only

You can also pattern-match against keys using the optional argument (Ruby 2.5+):

config = { host: "localhost", port: 8080, ssl: true }

config.any?(Symbol)
# => true

config.any?(String)
# => false

config.all?(Integer)
# => false (Symbol keys don't match)

The pattern argument form was added in Ruby 2.5 and uses the case-equality operator (===) to match each key. Passing Symbol checks whether any key is a symbol, String checks for string keys, and a Regexp matches against key names. This is a compact alternative to writing a block when all you need is a type or pattern check against keys.

Practical use cases

These methods are useful for validation:

form_data = { username: "john", email: "john@example.com", age: 25 }

# Validate all fields are present
form_data.all? { |(_k, v)| v&.to_s&.strip&.any? }
# => true

# Check if any field is empty
form_data.any? { |(_k, v)| v.nil? || v.to_s.strip.empty? }
# => false

# Verify no validation errors exist
errors = {}
errors.none?
# => true

These validation examples show how a single method call can replace several lines of manual iteration and conditional logic. When the predicate is simple — checking for presence, emptiness, or a value type — the method reads almost like a sentence describing the rule. More complex predicates can be extracted into named methods or lambdas to keep the call site readable.

Behavior with empty hashes

Ruby follows vacuous truth logic for empty collections:

{}.any?
# => false

{}.all?
# => true

{}.none?
# => true

This makes sense: an empty hash has no entries that could be false, so all entries pass and no entries fail the condition.

Common mistakes

The most common mistake is confusing any? with all?. any? answers “is there at least one match?”, while all? answers “do all entries match?” That distinction matters when a hash contains optional values or partially filled configuration.

Another mistake is assuming the empty hash should behave like false for every query. Ruby uses vacuous truth, so all? and none? return true on an empty hash. That can be surprising at first, but it matches how the methods are defined.

Conclusion

Hash#any?, Hash#all?, and Hash#none? keep boolean checks readable and close to the data they describe. They are simple methods, but they solve a lot of everyday validation and configuration checks cleanly.

Comparison

Method	Block returns true for	Result
any?	At least one entry	true if any match
all?	Every entry	true if all match (or hash empty)
none?	No entries	true if none match (or hash empty)

For everyday Ruby code, the choice usually comes down to intent. Use any? when one match is enough, all? when every entry must satisfy the rule, and none? when the absence of a match is the important part. That way the method name tells the reader exactly what you are checking.

Edge Cases

Truthy vs falsey values

{ a: false, b: nil }.any?
# => false (both are falsey)

{ a: false, b: nil }.all?
# => false (not all are truthy)

{ a: false, b: nil }.none?
# => true (none are truthy)

Ruby treats false and nil as the only falsey values, so any? without a block returns false when every entry holds one of these two values. This is consistent with how Ruby handles truthiness elsewhere, but it is worth keeping in mind when you store boolean flags in a hash and want to distinguish “no true values” from “no entries at all.”

Symbol vs string keys

{ :a => 1 }.any? { |(k, _v)| k == :a }
# => true

{ a => 1 }.any? { |(k, _v)| k == :a }
# => false

These methods are especially helpful in validation and configuration checks because they let you express the whole rule in one line. When that line gets too dense, consider extracting the block into a named predicate so the intent stays visible.

Common mistakes

The most common mistake is confusing any? with all?. any? answers “is there at least one match?”, while all? answers “do all entries match?” That distinction matters when a hash contains optional values or partially filled configuration.

Another mistake is assuming the empty hash should behave like false for every query. Ruby uses vacuous truth, so all? and none? return true on an empty hash. That can be surprising at first, but it matches how the methods are defined.

Conclusion

Hash#any?, Hash#all?, and Hash#none? keep boolean checks readable and close to the data they describe. They are simple methods, but they solve a lot of everyday validation and configuration checks cleanly.

See Also

• Hash#filter
• Hash#reject
• Hash#select