Array#all?

arr.all? { |element| block } -> true or false

Returns boolean· Updated May 30, 2026· Array Methods

arraysenumerableconditionalschecking

all? is an Enumerable method that tests whether every element in a collection matches a given condition. It returns true if all elements satisfy the criteria, otherwise false.

Syntax

array.all? { |element| block }

Without a block, it checks for truthy values. The method is part of Ruby’s Enumerable module, so it works on arrays, hashes, ranges, and any other class that includes Enumerable.

Parameters

Parameter	Type	Default	Description
`block`	`Proc`	—	A condition to evaluate against each element

Examples

Basic usage

numbers = [1, 2, 3, 4, 5]

numbers.all? { |n| n > 0 }
# => true (all numbers are positive)

numbers.all? { |n| n < 3 }
# => false (4 and 5 are not less than 3)

When you omit the block, all? tests each element for truthiness — nil and false are the only values that fail. This can be a quick sanity check that a collection contains no blanks, but it is less precise than an explicit block.

Without a block

[1, 2, 3].all?
# => true (all values are truthy)

[false, nil].all?
# => true (vacuous truth - no falsy values to contradict)

Starting in Ruby 3.0, you can pass a class or module directly to all? as a pattern. This checks that every element is an instance of that class — no block needed. It reads cleanly and avoids the boilerplate of all? { |x| x.is_a?(Integer) }.

With pattern matching (Ruby 3.0+)

items = [1, 2, 3]

items.all?(Integer)
# => true (all elements are integers)

Common Patterns

all? fits naturally into validation code where every item must pass the same rule. It is a single-method alternative to a manual loop with a flag variable, and the block makes the condition visible at the call site. Keeping the check self-contained like this means the reader does not have to hunt for what the validation is testing.

Validation checks

# Check if user input is valid
def valid_input?(answers)
  answers.all? { |a| a[:value].present? }
end

One of the method’s most useful properties is short-circuit evaluation. all? stops iterating the moment it finds a falsy result — it does not keep checking the remaining elements. This makes it efficient for large collections where a failure might appear early and further checks would waste time.

Short-circuit evaluation

all? stops after finding the first failure:

# Efficient: stops at first failing validation
users.all? { |u| validate_user(u) }

A subtle gotcha: all? returns true for an empty collection, following the principle of vacuous truth from formal logic. This surprises many developers who expect a falsy result from an empty array. Guard against this with an explicit size check when emptiness matters to your validation logic.

Errors

Note the vacuous truth behavior with empty arrays:

[].all?
# => true (this surprises many developers!)

Performance Notes

all? iterates lazily and stops as soon as it finds a falsy result, making it efficient for large datasets.

Checking that every item fits the rule

all? is the natural choice when the code needs every element to satisfy the same condition. It works well for validation, input checks, and quick guards because the method makes the rule obvious at the call site. The early exit behavior also keeps it efficient, since Ruby can stop as soon as a single failing value appears. That combination of clarity and short-circuiting makes all? one of the most readable collection checks in Ruby.

It is especially nice in code that treats a collection as a set of required conditions. The method lets the reader see the rule without tracing a separate loop, and it can keep validations compact when the check is simple. When the condition itself is the interesting part, all? makes that condition the star of the line instead of burying it inside a longer manual search.

That clarity is valuable in input validation and small guard clauses where the code should either accept the collection or reject it as a whole. By keeping the test in one place, the method reduces the amount of branching the reader has to track. It is a small helper, but it often makes the difference between a validation that is easy to read and one that feels scattered.