cc @stephentyrone

So is it OK for a future implementation to differ from the current implementation by silencing signaling NaNs?

I assume it is, but perhaps it's still worth to clarify?

Ie, let's rename the example implementation in the description to nextUp2, then:

let x = Float.signalingNaN
let currentImpl = x.nextUp
let exampleImpl = x.nextUp2
print(currentImpl.bitPattern == exampleImpl.bitPattern) // false
print(currentImpl.bitPattern == x.bitPattern) // true
print(exampleImpl.bitPattern == x.bitPattern) // false
print(currentImpl.isSignalingNaN) // true
print(exampleImpl.isSignalingNaN) // false
print(String(currentImpl.bitPattern, radix: 2))
print(String(exampleImpl.bitPattern, radix: 2))
// 1111111101000000000000000000000
// 1111111111000000000000000000000

This goes against (a perhaps too strict interpretation of) the documentation of .nextUp since x.nextUp2 is not x itself:
"For any finite value x, x.nextUp is greater than x. For nan or infinity, x.nextUp is x itself."

No, not too strict an interpretation. The IEEE standard specifically will point out where it is OK and not OK to silence NaN and we will need to check.

nextUp should silence signaling nans (and canonicalize results in formats that have non-canonical values), so this also fixes a bug.

More broadly, any operation that isn’t explicitly defined to preserve sNaN in 754 is expected to signal and return qNaN.

The documentation should really be read as “is x itself (canonicalized and silenced as appropriate).” This is a detail that I would say is out of scope for the documentation of an individual function, though perhaps we can come up with some standard terminology.

Faster versions of nextUp, ulp, and binade are included for Float and Double in PR #15021.

Thanks Xiaodi!

Convenience link: #15021