Feature #17773: Alias `Numeric#zero?` and `Float#zero?` as `Numeric#empty?` and `Float#empty?`

• Status: Open
• Assignee: -
• Target version: -

[sawa (Tsuyoshi Sawada)]

When dealing with user input fields as in web applications, there are typical values that we want to consider as the default and/or absence of user input. For string/text inputs, list items, and attributes, we have String#empty?, Array#empty?, and Hash#empty? respectively, which seem to correspond to those cases. As for numerics, there are Numeric#zero? and Float#zero?.

However, there is no single term that covers all these cases. In a routine to check through the fields whether there is user input, we have to selectively use empty? or zero? depending on the type of the input field.

Many programming languages other than Ruby typically consider these values as falsy with respect to logical calculation. Ruby handles only nil and false as falsy, and that has clear advantages in many aspects, but with the cost of losing a simple way to handle these default values.

I propose to alias Numeric#zero? as Numeric#empty? and Float#zero? as Float#empty? so that we can simply use empty?. At first, calling zero as empty might sound strange, but at least for non-negative integers, set theoretic definitions usually define zero as the empty set, so it is not that strange after all.

Ruby on Rails' blank? is conceptually similar to this, but 0.blank? returns false, so it is a different concept.

[sawa (Tsuyoshi Sawada)]

• Description updated (diff)

[jeremyevans0 (Jeremy Evans)]

I'm against this. empty? exists on collection classes, and numbers are not collections, nor sets. Can you provide a reference to a set theoretic definition of the number 0 as the empty set? Even if so, most Ruby programmers are not working in set theory and treating numbers as sets.

If you are checking for user input, aliasing zero? to empty? seems wrong, as 0 is a valid non-empty user input. In general, if you care whether a user input was empty, you should check whether a user input string is empty before converting it to a number, instead of after.

[sawa (Tsuyoshi Sawada)]

jeremyevans0 (Jeremy Evans) wrote in #note-2:

Can you provide a reference to a set theoretic definition of the number 0 as the empty set?

Here is a Wikipedia article:

https://en.wikipedia.org/wiki/Set-theoretic_definition_of_natural_numbers

[sawa (Tsuyoshi Sawada)]

jeremyevans0 (Jeremy Evans) wrote in #note-2:

If you are checking for user input, aliasing zero? to empty? seems wrong, as 0 is a valid non-empty user input.

I do not understand what you exactly mean by 0 is valid. But presumably, if 0 is valid in whatever sense you have in mind, then empty string is valid as well in the same sense. On the other hand, in some contexts, 0 is not valid, say, for a transfer amount in a bank transfer page, just as an empty string is not valid, say, in a required user's name field in a registration form.

On top of that, in the first place, the distinction in question is not valid vs. invalid. That is irrelevant. It is about explicit input vs. default.

[I}f you care whether a user input was empty, you should check whether a user input string is empty before converting it to a number, instead of after.

As for numeric fields, I am discussing cases where the default is 0 and the user did not change anything to the field, resulting in the return value 0. Empty string is irrelevant here.

[mrkn (Kenta Murata)]

I don't think these aliases are useful for most cases so it is inappropriate as a default-provided feature.
I agree there are cases that zero means empty, but there are also cases that -1 or other numbers mean empty. I don't think the zero case is the majority and special.

[marcandre (Marc-Andre Lafortune)]

I'm also against this proposal.

I do not believe that there are many cases where one checks for .zero? || .empty?. Note that nil nor false implement either.

If you need something like blank? or trivial? or similar, refinements are available.

[Eregon (Benoit Daloze)]

Same feeling here, empty? should be reserved for collections with elements.

Input fields from a website are always Strings initially, and should be checked as Strings (e.g., input.strip.empty?) for provided/not-provided.
The user might have provided "0" and that might be a correct value.

[sawa (Tsuyoshi Sawada)]

You may be right that zero is not (the only) special (element). In fact, one is the unit element for multiplication whereas zero is the unit element for addition. But still, addition is the first operation, and is more prominent than multiplication, which is the second operation. And the fact that we already have zero? method and the fact that many languages handle zero as falsy seem to indicate that indeed zero is special.

Regarding -1 (or other numbers) representing emptiness, I cannot recall clear instances. (Perhaps related to some sort of perpendicularity?) Can you give me some ideas?

[xtkoba (Tee KOBAYASHI)]

An example of using -1 as a default-ish integer value is to indicate "item not found" in a C-like language (see https://en.wikipedia.org/wiki/Sentinel_value).

The following example seems to suggest that Ruby treats 0 as a default-ish integer value in some cases.

p nil.to_i # => 0
p "".to_i # => 0

Yet I don't think that 0 should be treated as the special value in general, as long as we can freely assign both nil and an integer value to the same variable.