Project

General

Profile

Feature #14666

nil.any?{} should return false

Added by eike.rb (Eike Dierks) over 1 year ago. Updated over 1 year ago.

Status:
Rejected
Priority:
Normal
Assignee:
-
Target version:
-
[ruby-core:86460]

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

History

Updated by Student (Nathan Zook) over 1 year ago

.any? only makes sense on Enumerables. 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 1 year ago

  • Status changed from Open to Rejected
  • Description updated (diff)

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 1 year 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 1 year 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 1 year ago

Let's let nil remain nil rather than maybe become maybe-nil.

Also available in: Atom PDF