Issue #12110 has been updated by Andrew Vit.


Thanks Martin and Tsuyoshi, 

Yes, all of this makes sense when you just look at it the right way. 
Otherwise this basic equality wouldn't work either:

```
[].all? { true } == [].none? { false }
```

I'm not sure a new core method is justified anyway. It's easy to add ourselves
or even create a special implementation of enumerable:

```
# naive hack (!)
module Enumerable
  def nonempty
    dup.extend NonemptyIterators
  end
  
  module NonemptyIterators
    def all?
      !empty? && super
    end
    # ...
  end
end

[].all? { true }  # == true
[].nonempty.all? { true } # == false
```

I'm not sure I would like it to assume the natural language interpretation for me.
It might be enough that ruby core just provides the logic primitives.

----------------------------------------
Feature #12110: Create a method to avoid vacuous truth?
https://bugs.ruby-lang.org/issues/12110#change-57393

* Author: Waldyr de Souza
* Status: Open
* Priority: Normal
* Assignee: 
----------------------------------------
I often find myself running into unexpected results when using #all? for example

[].all? { |e| false } # => true

Even though it's logically correct could we have a method that express the following?

foo.any? && foo.all?(&:bar)



-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>