Enumerable#none?

Updated May 30, 2026· Enumerable

rubyenumerablenone?stdlib

What does `none?` do?

none? returns true if no element in the collection satisfies the given condition. If a block is provided, it tests each element against the block’s condition. If no block is given, it checks whether all elements are falsy (i.e., whether no element is truthy).

The method short-circuits — it stops iterating as soon as it finds an element that satisfies the condition, making it efficient for large collections.

Basic Usage

With a block

[1, 2, 3].none? { |n| n > 5 }   # => true
[1, 2, 3].none? { |n| n > 2 }   # => false (3 > 2)

The block form is the most explicit way to use none? because the condition is right there in the code. Each element is passed to the block, and the block’s return value determines whether the element counts as a match. A return of false or nil means “this element does not satisfy the condition, keep going.” A truthy return means “found one,” which immediately causes none? to return false because at least one element satisfied the test.

Without a block

When called without a block, none? checks for falsy values. Only nil and false are falsy — everything else is truthy:

[1, 2, 3].none?                 # => false (has truthy values)
[false, nil].none?              # => true
[false, nil, 1].none?           # => false (1 is truthy)
[].none?                         # => true (empty collection)

This makes none? useful for checking whether a collection is empty or contains no meaningful content at all.

With a predicate argument

You can pass a pattern object as an argument. The method treats it like a block that calls === on the pattern:

[1, 2, 3, 4].none?(Integer)        # => false (has integers)
[1, 2, 3, 4].none?(String)         # => true  (no strings)
["a", "b", "c"].none?(/x/)         # => true  (no x's)
["a", "b", "c"].none?(/b/)         # => false (has b's)

The pattern argument form works because Ruby’s case-equality operator === is defined differently for each class. For Integer, it checks numeric identity. For String, it checks string equality. For Regexp, it checks whether the regex matches the string. This is the same mechanism that powers case/when statements, so the predicate argument makes none? behave like a compact case-expression applied to every element. This is equivalent to:

[1, 2, 3, 4].none? { |n| Integer === n }  # => false

The pattern-argument shorthand is especially convenient with regular expressions and class objects because it eliminates the block boilerplate. Writing array.none?(Integer) reads almost like English and conveys exactly what is being checked. The same pattern works with ranges, procs, and any object that defines a meaningful === method, making it a flexible tool for quick membership and type checks.

Practical Examples

Checking that no number exceeds a limit

prices = [9.99, 14.99, 5.99, 22.50]

if prices.none? { |p| p > 100 }
  puts "All prices are under $100"
else
  puts "Some prices exceed $100"
end
# => All prices are under $100

Using none? to enforce an upper bound reads naturally because the test inside the block expresses the thing you want to rule out. When the block returns true for any element, none? returns false, which means the guard fails. The if/else branches around the none? call let you separate the happy path from the failure case without nesting logic inside the block itself.

Validating input

def all_positive?(numbers)
  numbers.none? { |n| n <= 0 }
end

all_positive?([1, 2, 3, 4])    # => true
all_positive?([1, -2, 3])     # => false

The all_positive? wrapper shows how none? can express a positive assertion through a negative test. Saying “none are non-positive” is logically equivalent to “all are positive,” but the two phrasings carry different cognitive weight. When the natural way to describe the condition is in negative terms, none? is often the clearer choice. When the condition feels more natural expressed positively, all? may be the better fit.

Checking for absence of a pattern

emails = ["alice@example.com", "bob@test.org", "charlie@domain.net"]

emails.none? { |email| email.end_with?(".gov") }   # => true
emails.none? { |email| email.include?("admin") }  # => true

none? paired with end_with? or include? is a natural fit for filtering by domain or keyword. Each email in the collection is tested against a simple predicate, and the method short-circuits the moment it finds a hit. For a list of thousands of addresses, a match near the front returns false instantly, while a true none? result (no matches at all) requires scanning the entire collection.

Avoiding nil before processing

def log_message(msg)
  return if messages.none?
  # process messages...
end

log_message([])        # => nil (early return)
log_message(["hi"])    # => continues

Using none? as a guard before processing avoids a common nil-handling pattern. Instead of checking each element for nil inside a loop, you check once at the top and skip the entire processing block when the collection is empty or contains only nil values. This separates the “nothing to do” case from the processing logic and keeps the main loop focused on the actual work.

Short-Circuit Evaluation

none? stops as soon as it finds an element that satisfies the block’s condition (returns true). This matters when the block has side effects or when performance is critical:

# Stops after finding the first matching element
[1, 2, 3, 4].none? do |n|
  puts "Checking #{n}"  # This prints only for 1, 2, 3
  n > 2
end
# => false
# Output:
# Checking 1
# Checking 2
# Checking 3

The puts statement inside the block reveals exactly when the iteration stops. Ruby checks element 1 (1 is not greater than 2, continue), element 2 (2 is not greater than 2, continue), and element 3 (3 is greater than 2, stop). Element 4 is never inspected because the result is already determined: at least one element satisfies the condition, so none? can return false without finishing the collection. This early exit is what makes none? safe to use on large collections even when matches are likely.

Empty collections

none? always returns true for an empty collection, regardless of the block:

[].none? { |x| x > 5 }   # => true
[].none?                  # => true

An empty collection returning true from none? is consistent with the logic: if there are no elements, then there is no element that satisfies the condition. Ruby does not need to call the block at all because the answer follows from the collection’s size alone. This is the same principle that makes [].all? { false } return true, which can feel counterintuitive at first but follows from the mathematical definition of universal quantification over an empty set.

Performance Considerations

Lazy evaluation

Because none? short-circuits, the worst case (no element matches) requires checking every element, but the best case (first element matches) exits immediately:

# Worst case: O(n) - checks all elements
[1, 2, 3].none? { |n| n > 100 }  # => true, checks all 3

# Best case: O(1) - stops at first element
[100, 200, 300].none? { |n| n > 50 }  # => false, stops at first element

The best case exits in O(1) time because the very first element already violates the “none” condition. The worst case visits every element and still returns true, meaning O(n) checks were performed and none of them found a match. When you expect matches to be rare and the collection is large, none? costs O(n). When matches are common near the front, none? is effectively O(1). This asymmetry in performance means the method’s cost depends more on your data than on the collection size alone.

Arrays vs Sets

For membership testing, none? over an array performs linear search. If you frequently check whether any element matches a value, consider a Hash or Set:

require "set"

blocked_tags = Set.new(["spam", "banned", "deleted"])

# Array: O(n) linear search each time
content_tags = ["ruby", "python", "go"]
content_tags.none? { |tag| tag == "spam" }  # => true

# Set: O(1) lookup
blocked_tags.none? { |tag| tag == "spam" }  # => false

Relationship to `any?` and `all?`

none? is the complement of any? and the inverse of all?:

Method	Returns true when…
`any?`	At least one element satisfies the condition
`all?`	Every element satisfies the condition
`none?`	No element satisfies the condition

# none? vs any?
[1, 2, 3].none? { |n| n > 5 }    # => true  (no element is > 5)
[1, 2, 3].any? { |n| n > 5 }     # => false

# none? vs all?
[1, 2, 3].none? { |n| n > 2 }   # => false (3 > 2, so an element does satisfy)
[1, 2, 3].all? { |n| n > 2 }    # => false (1 and 2 don't satisfy)

# Logical equivalences
[1, 2, 3].none? { |x| condition }
# is equivalent to:
![1, 2, 3].any? { |x| condition }

This logical equivalence between none? and negated any? means you can refactor between the two forms freely. The right choice depends on which phrasing makes the intent clearer. A guard that reads return if items.none? is more direct than return unless items.any?, even though both produce the same boolean result. Prefer the form that matches how you would describe the condition out loud: negative conditions suit none?, positive ones suit any? or all?.

You can often choose between any? and none? based on readability:

# These are equivalent:
collection.none? { |x| x.nil? }
!collection.any? { |x| x.nil? }

What does none? do?