make matching on NaN a hard error, and remove the rest of illegal_floating_point_literal_pattern

[RalfJung]

These arms would never be hit anyway, so the pattern makes little sense. We have had a future-compat lint against float matches in general for a long time, so I hope we can get away with immediately making this a hard error.

This is part of implementing rust-lang/rfcs#3535.

Closes #41620 by removing the lint.

rust-lang/reference#1456 updates the reference to match.

[rustbot]

r? @cjgillot

(rustbot has picked a reviewer for you, use r? to override)

[rustbot]

Some changes occurred to the CTFE / Miri engine

cc @rust-lang/miri

Some changes might have occurred in exhaustiveness checking

cc @Nadrieril

[RalfJung]

@bors try

[bors]

⌛ Trying commit 92ddac2 with merge a3e4be4...

[bors]

☀️ Try build successful - checks-actions
Build commit: a3e4be4 (a3e4be48b4c3670ac65b4a34314d0d9527a4941d)

[RalfJung]

All right let's see what crater finds @craterbot check

[craterbot]

👌 Experiment pr-116284 created and queued.
🤖 Automatically detected try build a3e4be4
🔍 You can check out the queue and this experiment's details.

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

[craterbot]

🚧 Experiment pr-116284 is now running

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

[asquared31415]

It would be nice if there were justification/explanation in a note in the error message, maybe something like "NaN never matches any float, including identical NaNs"?

Maybe also hint that {float}::is_nan exists?

Otherwise I can see many complaints about "why won't the compiler let me check that something is NaN with a match" from people that don't understand why it's not permitted.

[RalfJung]

Yeah if crater comes back with the results I hope we can improve the diagnostics.

[craterbot]

🎉 Experiment pr-116284 is completed!
📊 11 regressed and 0 fixed (373232 total)
📰 Open the full report.

⚠️ If you notice any spurious failure please add them to the blacklist!
ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

[RalfJung]

These all look spurious. :)

@rust-lang/lang this is basically a trimmed-down version of #84045 that only makes matching specifically on NaNs a hard error. Those match arms are impossible to hit, so there's no way these arms are actually useful.

[nikomatsakis]

@RalfJung We discussed this in the lang-team meeting today. We had some questions:

• First, what is the motivation to eliminate NaN specifically? Is it simply that NaN is confusing for end-users (because it is not equal to itself, and hence the arm is dead code) or is it because NaN itself adds some difficulties to const generics or other things?
• Second, do we have a sense for the overall "plan" around the semantics of pattern matching and floating point values? At some point we expected to remove that, but now it seems like we are allowing floats, presumably with today's semantics, is that correct?

Our preliminary feeling at the meeting was that singling out NaN felt strange...

• If we are going to allow matching on floats, @scottmcm and myself, at least, would prefer to lint against matching on NaN, as it could be quite surprising, but not make it a hard error.
• If we are going to disallow all float matching, then, this is a different thing.

[RalfJung]

First, what is the motivation to eliminate NaN specifically?

NaN is by far the least well-behaved class of float values when it comes to comparison, since they don't even satisfy reflexivity. No matter the mental model for match, it seems very hard to justify a value not even matching itself.

Second, do we have a sense for the overall "plan" around the semantics of pattern matching and floating point values? At some point we expected to remove that, but now it seems like we are allowing floats, presumably with today's semantics, is that correct?

There was the plan to disallow floats entirely as part of the move to enforcing structural matching (this even got RFC'd). Then t-lang rejected #84045, which is a departure from that plan. If t-lang has a long-term plan here than you didn't tell us about it. :)

[saethlin]

• If we are going to allow matching on floats, @scottmcm and myself, at least, would prefer to lint against matching on NaN, as it could be quite surprising, but not make it a hard error.

A future-incompat lint that covers all float matches already exists: #41293

[scottmcm]

If t-lang has a long-term plan here than you didn't tell us about it. :)

Yeah, we agree we need a plan :) We opened rust-lang/lang-team#222 so that the planning meeting tomorrow can hopefully schedule something about it

---

Personally I'm super-torn about it. I agree that NANs are weird and it's be great to just disallow them with extreme prejudice, but at the same time if we're allowing matching on floats in general as "it's like PartialEq" then it trips all my heuristics for "that's a lint" because we know what it does it's just not what people wanted to use.

[workingjubilee]

I believe we should not use PartialEq as the basis of match, and especially not in this case. It is irritatingly recursive to begin with (generally, when writing PartialEq impls, I use match to avoid having to reason about the existence of other PartialEq impls) and encourages needless semantic drift between a match arm described by a constant and a match arm described by a pattern.