Matching on floating-point literal values is totally allowed and shouldn't be

[carols10cents]

Per this comment on the tracking issue for disallowing the use of constants set to floating point numbers (which errors as expected today), @nikomatsakis says the intention was to disallow floating point literal values in matches, but uh... this is totally accepted by Rust 1.16.0:

fn main() {
    let x = 13.4;

    match x {
        1.0 => println!("one"),
        22.4 => println!("two"),
        3.67 => println!("three"),
        13.4 => println!("thirteen point four"),
        _ => println!("anything"),
    }
}

This prints "thirteen point four". I expected to get a compiler error like the one I get if I change a floating point value in the match to a constant:

const FOO: f64 = 3.67;

fn main() {
    let x = 13.4;

    match x {
        1.0 => println!("one"),
        22.4 => println!("two"),
        FOO => println!("three"),
        13.4 => println!("thirteen point four"),
        _ => println!("anything"),
    }
}

results in:

error: floating point constants cannot be used in patterns, #[deny(illegal_floating_point_constant_pattern)] on by default
 --> src/main.rs:9:9
  |
9 |         FOO => println!("three"),
  |         ^^^
  |
  = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
  = note: for more information, see issue #36890 <https://github.com/rust-lang/rust/issues/36890>

[est31]

There seem to be three options:

• we add literals to the existing compatibility lint without changing the status, this would immediately deny the code above by default
• we add literals to the existing compatibility lint and change it to warn by default, and sometime in the future set it to deny by default again
• we create a new lint and set it to warn by default, making two consecutive breaks

idk maybe a crater run should be done to find out what is best.

[nikomatsakis]

@est31 indeed, a crater run seems warranted.

[nikomatsakis]

Nominating for compiler team discussion on best way to proceed and prioritization. Seems to me we ought to settle this pretty quickly one way or another.

[nikomatsakis]

triage: P-high

This is time-sensitive, so we gotta act if we are ever going to. Assigning to @pnkfelix.

[est31]

I've filed two PRs #41292 for removing the use of a floating point match from the compiler and #41293 for a crater run to test the most strict solution -- to add it to the existing lint without changing the deny-by-default status. Independent from whether that strategy will be chosen in the end, it gives us an initial number of crates that would be affected by the change.

#41293 includes #41292 already to make a crater run possible without #41292 being merged.

[petrochenkov]

This is arguable.

Floats are built-in types known to the compiler, you don't have to run any user-defined code to match on them.
Matching being "bitwise" is also not a goal - references, for example, are matched semantically and not as pointer values, and everyone is happy about it. Floats can be compared semantically as well.

Another analogy is that float literals are the same thing as variants for non-structural_match enums, as opposed to constants. So even if constants are prohibited, variants still can be used:

match xxx {
    NON_STRUCTURAL_MATCH_CONST => {} // Not OK, constant
    NonStructuralMatch { field } => {} // OK, variant
    FLOAT_CONST => {} // Not OK, constant
    1.0 => {} // OK, variant
}