rubyguides

Hash#all? 

hash.all? { |key, value| block } → true or false
Returns Boolean· Added in v1.8.7· Updated May 30, 2026· Hash Methods
rubyhashenumerableboolean

Hash#all? returns true if every key-value pair in the hash satisfies a given condition. It is inherited from Enumerable, which Hash includes. It has three forms: a block, a pattern argument, and a no-argument form.

Syntax

hash.all?                            # → true or false
hash.all?(pattern)                   # → true or false
hash.all? { |key, value| ... }       # → true or false

Parameters

ParameterTypeRequiredDescription
patternObjectNoMatched against each [key, value] pair using ===
blockProcNoReceives key and value; truthy return means the pair matches

Return Value

Always returns true or false. Short-circuits on the first false — it stops iterating as soon as it finds a pair that does not match.

How each form works

Block form

The block receives two arguments: the key and value for each pair. If the block returns false or nil for any pair, all? returns false immediately.

scores = { alice: 95, bob: 72, carol: 88 }

scores.all? { |name, score| score > 60 }
# => true  (all scores above 60)

scores.all? { |name, score| score >= 88 }
# => false  (bob: 72 is below 88)

The block receives both the key and the value, which means you can write conditions that inspect either one independently. This is one of the advantages of using a map with all? instead of iterating over just the values: you get the names alongside the data, so the condition can refer to both. For instance, you might want to verify that certain keys are absent while other values meet specific thresholds, all in a single pass through the collection:

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

config.all? { |key, value| key != :debug }
# => true  (no :debug key present)

config.all? { |key, value| value != false }
# => false  (ssl: false fails)

No-argument form

When you call all? without a block, Ruby checks the truthiness of each value directly rather than evaluating a custom condition. This is a simpler form that works well for quick existence checks — if every value in the hash is truthy (meaning it is not false and not nil), the method returns true. Falsy values are false and nil, so any occurrence of either will immediately cause all? to return false. This shorthand is concise but limited: it cannot express compound conditions like “all values greater than 10” or “all keys are symbols.” For those cases, the block form is the right tool.

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

{ a: true, b: "string" }.all?
# => true

{ a: false, b: 1 }.all?
# => false  (false is falsy)

{ a: nil, b: 2 }.all?
# => false  (nil is falsy)

{}.all?
# => true

An empty hash always returns true with the no-argument form. This is mathematically sound — it is vacuously true because there are no pairs to violate the condition — but it often surprises developers who expect false from an empty collection. The same behaviour occurs with the block form: {}.all? { |k, v| ... } returns true because the block never runs, so no pair can fail the test. This is consistent with how Enumerable#all? works across all collection types, but it is worth keeping in mind when you write guard conditions that depend on the presence of entries.

Pattern form

With a pattern argument, all? checks whether pattern === element is true for every element. For a Hash, each element is a [key, value] array, so the pattern is matched against those pairs.

inventory = { apples: 10, bananas: 0, cherries: 50 }

# Check if all pairs match the exact pair
inventory.all?([:apples, 10])
# => false  (other pairs don't match)

# Array matches any two-element pair
inventory.all?(Array)
# => true  (all pairs are two-element arrays)

# Integer checks if pair itself is an Integer (always false)
inventory.all?(Integer)
# => false

The pattern form is rarely used with Hash because it matches entire [key, value] pairs, not individual keys or values. A class pattern like Integer tests whether each pair array is an instance of Integer — which it never is, since pairs are always Array objects. The block form is almost always more readable and more flexible for hash-specific conditions. If you do use the pattern form, remember that you are matching against two-element arrays, so only patterns that make sense for arrays will produce useful results.

Common use cases

Validating all entries pass a test

def all_positive?(numbers)
  numbers.all? { |_k, v| v > 0 }
end

temperatures = { monday: 18, tuesday: 22, wednesday: 19 }
all_positive?(temperatures)
# => true

The block arguments _k and v let you ignore the key and check only the value. The underscore prefix on _k is a Ruby convention that signals “this argument is intentionally unused,” which keeps the block readable when the key name does not matter for the condition being tested. You can also destructure the pair differently if you only need the key.

Checking complete configuration validity

required_keys = [:host, :port, :ssl]
config = { host: "localhost", port: 8080, ssl: false }

has_all_keys = required_keys.all? { |k| config.key?(k) }
# => true  (all required keys are present)

# Then separately check values
all_values_set = config.all? { |_k, v| v != nil }
# => true  (no nil values)

This two-step pattern — check for key presence first, then validate values — is a common idiom when the requirements are layered. Splitting the checks into separate all? calls makes each condition easier to read and easier to debug independently. If either step fails, the code can report exactly which check went wrong rather than returning a single undifferentiated false.

Guard conditions

def run_tasks(tasks)
  return if tasks.all? { |_name, task| task[:enabled] }

  # Not all tasks are enabled — do something else
  puts "Some tasks are disabled, skipping."
end

tasks = { upload: { enabled: true, url: "..." }, cleanup: { enabled: true } }
run_tasks(tasks)  # all enabled → returns early

Gotchas

Empty hash returns true. {}.all? { |k, v| something } returns true even though the block never runs. This is a consequence of vacuous truth in predicate logic: a universal statement about an empty set is considered true because there is no counterexample to refute it. While this is logically rigorous, it can surprise developers who use all? as an implicit “collection is non-empty and all entries pass” check. If you need different behaviour for an empty hash, check .empty? first:

{}.all? { |k, v| k == :missing }
# => true  (vacuous truth — nothing to contradict the condition)

# If you want false for an empty hash:
hash.empty? ? false : hash.all? { |k, v| condition }

No-argument form checks truthiness of values, not key presence. { a: nil }.all? returns false because nil is falsy, not because the key is missing. This trips people up when they use all? as a proxy for “all keys present.”

Short-circuit evaluation. all? stops on the first non-matching pair. For large hashes this is efficient, but it also means side effects in the block are not guaranteed across all entries:

results = {}
hash.all? do |k, v|
  results[k] = process(v)  # may not run for all keys
  v.valid?                  # short-circuits here
end

If every entry must be processed, use Hash#each_value or Hash#map instead.

Pattern form matches entire pairs. A class pattern like Integer tests whether each [key, value] array is an Integer — it never is. Use a block for value-type checks:

data = { count: 5, label: "items" }

# Wrong: checks if pair is an Integer (always false)
data.all?(Integer)
# => false

# Right: checks if every value is an Integer
data.all? { |_k, v| v.is_a?(Integer) }
# => false  (label is a String)

See Also