Conversation
* 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
left a comment
There was a problem hiding this comment.
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). |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
"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". |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Did you read my commit message?
There was a problem hiding this comment.
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.
Description
isFinite()examples to level up with comments inisNaN().isFinite()Return value section to emphasize thatisFinite()always returnstrue, except in three cases.nullas one of three surprising exceptional cases to the description ofisNaN()because I believe this is more surprising than thebooleancase which is a rather common and unsurprising scenario in other computer languages.Motivation
To me, the original sections were ambiguous.
For
isFinite(), Thefalsecase had been too prominent while thetruecase had insufficient attention. The examples were not informative enough.For
isNaN(), I believe thenullcase was missing because, to mee, thenullcoercion seems the most surprising case. In SQL, for example,nullis explicitly not a number.