[#74190] [Ruby trunk Feature#12134] Comparison between `true` and `false` — duerst@...
Issue #12134 has been updated by Martin D端rst.
3 messages
2016/03/07
[#74269] Type systems for Ruby — Rob Blanco <ml@...>
Dear ruby-core,
5 messages
2016/03/10
[#74395] [Ruby trunk Feature#12142] Hash tables with open addressing — shyouhei@...
Issue #12142 has been updated by Shyouhei Urabe.
3 messages
2016/03/17
[ruby-core:74261] [Ruby trunk Feature#12110] Create a method to avoid vacuous truth?
From:
andrew@...
Date:
2016-03-10 07:24:47 UTC
List:
ruby-core #74261
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>