Skip to content

Explanation improved on the results of isFinite() and isNaN() - #45682

Open
SetTrend wants to merge 1 commit into
mdn:mainfrom
SetTrend:isFinite
Open

SetTrend wants to merge 1 commit into
mdn:mainfrom
SetTrend:isFinite

Conversation

@SetTrend

Copy link
Copy Markdown

Description

  • Comments added to isFinite() examples to level up with comments in isNaN().
  • Changed the explanation in isFinite() Return value section to emphasize that isFinite() always returns true, except in three cases.
  • Added description for null as one of three surprising exceptional cases to the description of isNaN() because I believe this is more surprising than the boolean case which is a rather common and unsurprising scenario in other computer languages.

Motivation

To me, the original sections were ambiguous.

For isFinite(), The false case had been too prominent while the true case had insufficient attention. The examples were not informative enough.

For isNaN(), I believe the null case was missing because, to mee, the null coercion seems the most surprising case. In SQL, for example, null is explicitly not a number.

@SetTrend
SetTrend requested a review from a team as a code owner September 13, 2026 17:17
@SetTrend
SetTrend requested review from Josh-Cena and removed request for a team September 13, 2026 17:17
@github-actions github-actions Bot added Content:JS JavaScript docs size/s [PR only] 6-50 LoC changed labels Sep 13, 2026
* Comments added to `isFinite()` examples to level up with comments in `isNaN()`.
* Changed the explanation in `isFinite()` **Return value** section to emphasize that `isFinite()` always returns `true`, except in three cases.
* Added description for `null` as one of three surprising exceptional cases to the description of `isNaN()` because I believe this is more surprising than the `boolean` case which is a rather common and unsurprising scenario in other computer languages.

@Josh-Cena Josh-Cena left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can't see how most of the changes here, other than the additional examples, are improvements, so more context would be needed.

### Return value

`false` if the given value is {{jsxref("NaN")}}, {{jsxref("Infinity")}}, or `-Infinity` after being [converted to a number](/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number#number_coercion); otherwise, `true`.
`true`, except when the given value is either `-`{{jsxref("Infinity")}}, {{jsxref("Infinity")}}, or {{jsxref("NaN")}} after being [coerced to a number](/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number#number_coercion).

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can't see how this makes a difference. You either get true or false, and it's equivalent to state the condition for either of them. I picked false because otherwise you have to use a negative "except" which is strictly worse for comprehension.

Also "converted" and "coerced" are equivalent in this context, I usually consistently use "convert" because there's no reason to pick and choose.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe it's easier to grasp when it first states the most important, common, surprising and, thus, informative part: "Always return true" … then followed by the – rather non-surprising – three exceptions.

The author of isNaN() preferred the term "coerced". "converted" rather implies a bijective application. "coerced" rather implies a surjective application.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"Converted" and "coerced" are precisely defined terms on MDN: https://developer.mozilla.org/en-US/docs/Glossary/Type_coercion. Your definition suggests that "conversion" is a subset of "coercion", but on MDN, it's the reverse: all coercion is conversion.

For number values, `isNaN()` tests if the number is the value [`NaN`](/en-US/docs/Web/JavaScript/Reference/Global_Objects/NaN). When the argument to the `isNaN()` function is not of type [Number](/en-US/docs/Web/JavaScript/Guide/Data_structures#number_type), the value is first coerced to a number, and the resulting value is then compared against {{jsxref("NaN")}}.

This behavior of `isNaN()` for non-numeric arguments can be confusing! For example, an empty string is coerced to 0, while a boolean is coerced to 0 or 1; both values are intuitively "not numbers", but they don't evaluate to `NaN`, so `isNaN()` returns `false`. Therefore, `isNaN()` answers neither the question "is the input the floating point {{jsxref("NaN")}} value" nor the question "is the input not a number".
This behavior of `isNaN()` for non-numeric arguments can be confusing! For example, [`null`](/en-US/docs/Web/JavaScript/Guide/Data_structures#null_type) is coerced to 0, an empty string is coerced to 0, and a boolean is coerced to 0 or 1; these values are intuitively "not numbers", but they don't evaluate to `NaN`, so `isNaN()` returns `false`. Therefore, `isNaN()` answers neither the question "is the input the floating point {{jsxref("NaN")}} value" nor the question "is the input not a number".

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure why we need three examples as opposed to two? The point is not to list every common data type. The point is only to say that they are not NaN.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did you read my commit message?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I still don't get it. All these are equally surprising because none of them are either numbers or NaN. If you'd really like, I guess I'm okay with replacing "boolean" with null but we should keep it to be two examples at most.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Content:JS JavaScript docs size/s [PR only] 6-50 LoC changed

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants