There is no way to check if a potentially constant double is `NaN`

[mateusfccp]

According to the the IEEE-754 specification, NaN is never equal to any double, even to NaN (!!). Because of this, if one wants to know if a given double is NaN, they should use .isNaN instead.

See also #44649 and #50481, which are related to a lint to prevent comparison with NaN (like myDouble == double.nan).

The problem is that we have no way to check if a potentially constant value is NaN.

Example:

// Tentative 1: won't work, as the comparison will always return false
final class NonNanDouble {
  const NonNanDouble(this.value) : assert(value != double.nan); // A double can't equal 'double.nan', so the condition is always 'true'. Try using `double.isNaN', or removing the condition.

  final double value;
}

// Tentative 2: won't even compile, as `value.isNaN` is not a constant value
final class NonNanDouble {
  const NonNanDouble(this.value) : assert(value.isNaN); // Invalid constant value

  final double value;
}

If we want to do this check we have to resign the constant constructor.

// Workaround: now we can't have constant values for the class
final class NonNanDouble {
  NonNanDouble(this.value) : assert(value.isNaN);

  final double value;
}

[lrhn]

If you know it's a number, you can do value != value. That should only be true for NaN. (And only true for NaN among non-numbers too if they are not doing something similarly bad with their ==, which nobody should.)

Also, identical(value, double.nan) has a chance of working on the VM. Never on the web, though.

If we had a === operator, which would not be user-definable, I'd make it be true for two NaN values. Probably be identity otherwise. Which means almost like identical, except that it canonicalizes different NaN values (there are 2^52-2 of them).

[lrhn]

It is, however, not trivial to match NaN in patterns. You have to do double(isNaN: true).

We could consider special-casing a constant pattern with the value of double.nan, or any NaN value, to mean double(isNaN: true), instead of just being completely useless.
(A case double.nan: can never match. A case == double.nan: can, technically, if the matched object has a weird operator== which definitely won't be symmetric. That's why I'd only special case the constant pattern, not == double.nan.)

It's special-casing, which is icky, but NaN already has special-cased itself when it comes to equality, so this would just be helping the user deal with that.

[eernstg]

If we introduce some additional primitive members, cf. dart-lang/language#2219, then isNaN is already lined up as a candidate.

[mateusfccp]

If we introduce some additional primitive members, cf. dart-lang/language#2219, then isNaN is already lined up as a candidate.

I had completely forgotten about this issue, thanks for bringing it up!

[mraleph]

Closed in favor of the existing language issue.