f*::NAN: guarantee that this is a quiet NaN

[RalfJung]

I think we should guarantee that this is a quiet NaN. This then implies that programs not using f*::from_bits (or unsafe type conversions) are guaranteed to only work with quiet NaNs. It would be awkward if people start to write 0.0 / 0.0 instead of using the constant just because they want to get a guaranteed-quiet NaN.

This is a @rust-lang/libs-api change. The definition of this constant currently is 0.0 / 0.0, which is already guaranteed to be a quiet NaN. So all this does is forward that guarantee to our users.

[rustbot]

r? @thomcc

rustbot has assigned @thomcc.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[m-ou-se]

@rfcbot merge

[rfcbot]

Team member @m-ou-se has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @m-ou-se

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[rustbot]

The Miri subtree was changed

cc @rust-lang/miri

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[bstrie]

Is it worth considering the alternative of making no guarantees about f*::NAN, and instead providing f*::QUIET_NAN and f*::SIGNALING_NAN?

[RalfJung]

I think adding a SIGNALING_NAN might be worth considering, but I'd say NAN is the better name for QUIET_NAN since it's what you should use most of the time. Signaling NaNs show non-portable behavior much more quickly than quiet NaNs.