Feature #14666
closednil.any?{} should return false
Description
Hi everyone at ruby/trunk
I encountered nil.any?
undefined method `any?' for nil:NilClass (NoMethodError)
I fully agree with all of yours,
that nil
should be kept slim.
But than, on the other hand,
the existence quantors are well defined on nil
.
So nil.any?
should always return false
I know this might make more sense to return NoMethodError
But in the end nil
is an object,
it's not a null pointer exception any more
We can actually talk with nil
.
Back in the objc days talking to nil
would always return nil
,
Im not sure what happens if nil
answers false
to any?
(currently it throws an exception, code should not depend on that)
I believe nil
is a deep concept,
and ruby got far ahead with the Nil class
I'd like to suggest that nil.any?{}
should return false
Updated by Student (Nathan Zook) over 6 years ago
.any?
only makes sense on Enumerable
s. There is no end to the methods that we would need to define on nil
if we went this route.
-1
Updated by nobu (Nobuyoshi Nakada) over 6 years ago
- Description updated (diff)
- Status changed from Open to Rejected
any?
, all?
, and the family can be defined only on container objects from the meanings.
nil
is not a container object.
Updated by eike.rb (Eike Dierks) over 6 years ago
I fully aggree with all the commenters.
It boils down to if nil should be Enumerable.
Obviously it should be not. because nil is special.
But then nil means "not in list" or the empty list or the not existing list?
I know this might break some code.
But the other way around, it might fix a lot more of code.
Please think of what nil means.
It does not mean: just crash immediately whenever you encounter a nil.
Actually nil does have a very well defined semantics in ruby.
I agree, nil has never been Enumerable
because not in list is not a list
maybe I just want to provoke a discussion on this.
so please feel invited to discuss this topic
I'm looking forward to make Enumerables even more orthogonal
because this where ruby really shines
Please excuse if I came up with discussing nil,
all of you are absolutely right that nil should stay the way it is.
(I'm really happy with that)
So later in the end, we might come up
we might come up with a better definition, what nil really is
I'm looking forward for this for ruby 3,
to precisely define all aspects of nil
All of your comments are welcome
Updated by Eregon (Benoit Daloze) over 6 years ago
This could maybe be achieved in user code by adding some kind of Optional/Maybe construct, which could include Enumerable.
Then it would behave either as an empty Array or an Array of one element, based on whether it contains a value.
def Maybe(v)
v.nil? ? [] : [v]
end
Maybe(method_which_might_return_nil()).any? # but also map, each, ...
Updated by shevegen (Robert A. Heiler) over 6 years ago
Let's let nil remain nil rather than maybe become maybe-nil.