Array#none?
arr.none? { |element| block } -> true or false none? is an Enumerable method that tests whether no element in a collection matches a given condition. It returns true if no elements satisfy the criteria, otherwise false.
Syntax
array.none? { |element| block }
Without a block, it checks for truthy values. none? 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.none? { |n| n < 0 }
# => true (no negative numbers)
numbers.none? { |n| n > 10 }
# => true
When you omit the block, none? checks each element for truthiness — it returns true only if every element is nil or false. This is a stricter version of the pattern-match version and is most useful as a quick emptiness-or-falsity check.
Without a block
[false, nil].none?
# => true (no truthy values)
[0, false, nil].none?
# => true
Starting in Ruby 3.0, you can pass a class or module directly to none? as a pattern. This checks that no element is an instance of that class — a clean alternative to none? { |x| x.is_a?(String) } that reads more like a plain statement of intent.
With pattern matching (Ruby 3.0+)
items = [1, 2, 3]
items.none?(String)
# => true (no string elements)
Common Patterns
none? shines in guard clauses where the desired state is the absence of a condition. Instead of checking for a match and then negating the result, the method name says what you want directly: no item should match the given rule. This keeps the intent obvious at a glance.
Validation checks
# Ensure no duplicates exist
def unique?(collection)
collection.none? { |x| collection.count(x) > 1 }
end
Like its sibling all?, none? short-circuits — it stops iterating the moment it finds a truthy result. This keeps the method efficient for large collections where a violating element might appear early and further checks would be wasted effort.
Short-circuit evaluation
none? stops after finding the first truthy result:
# Efficient: stops at first invalid item
items.none? { |i| invalid?(i) }
A quirk worth remembering: none? returns true for an empty collection, following the same vacuous truth logic as all?. An empty array has no elements that violate the condition, so the method considers the check satisfied. When emptiness itself should be a failure, add an explicit guard.
Errors
Empty arrays always return true:
[].none?
# => true
Performance Notes
none? iterates lazily and stops as soon as it finds a truthy result, making it efficient for large datasets.
Checking for the absence of matches
none? is a good fit when the code needs to prove that nothing in a collection meets a certain rule. That can be a helpful way to write validations, especially when the positive case is not the focus. The method keeps the condition readable and lets Ruby stop early once the answer is known. When the block is simple, the resulting code reads almost like plain language: no item should match this condition.
It is especially useful in guard clauses because the name itself describes the desired outcome. Rather than checking for a match and then negating the result, the code can state the rule directly. That makes the branch easier to read and reduces the mental step the caller has to take. For collection checks that only care about the absence of a condition, none? keeps the code short and the intent obvious.
It also pairs nicely with validation code that wants to reject a collection if any item is out of line. The method gives the caller a compact way to express “nothing here should match,” which is often clearer than building a manual counter. That direct phrasing is part of why none? is so readable in short conditions.
# Guard clause pattern
return if items.none? { |i| i.blank? }
# process items knowing none are blank
In a broader sense, none? sits in the same family as the other collection predicates, but it describes the negative case without forcing the caller to invert the result in its head. That tiny difference can make a branch feel easier to trust, because the code reads like a short rule instead of a puzzle.
# Contrast: negating any? vs using none? directly
elements.none? { |e| e.nil? } # intent: confirm nothing is nil
!elements.any? { |e| e.nil? } # harder to read: negate any-match
That tiny difference can make a branch feel easier to trust. When the code is reading like a short rule instead of a puzzle, the result is usually easier to maintain.
The method also helps when a check needs to fail fast before a larger operation runs. If nothing matches the unwanted condition, the program can keep going without building a separate loop or temporary counter. That keeps the validation narrow, which is often exactly what a guard clause should do.
That narrow focus is part of why none? reads so cleanly in code review. The line says what should not be present, and the block says which rule matters. There is very little hidden bookkeeping, so the control flow stays easy to follow even when the collection itself is large. It is a compact way to state a negative requirement.
See Also
- Array#all? — checks if every element matches a condition
- Array#any? — checks if at least one element matches
- Array#one? — checks if exactly one element matches