`f32::from(<untyped float>)` inference with `f16` and `f128`

[tgross35]

Adding a From<f16> for f32 impl breaks some inference that currently works. From #123824:

fn main() {
    let x = f32::from(3.14);
}

The new float types are a long way from being stable, but it may be good to decide how to handle things if we would like this implementation one day. Per @fmease at #123824 (comment), there are three options:

1. Accept this regression since technically, no stable API is broken
2. Say that we do not want From<f16> for f32
3. Make this implementation available starting with the new edition

I'll mark this with the edition label so it can at least come into consideration, but this is the lowest priority thing on any list.

Known failure points from adding this directly:

• Fuchsia: https://cs.opensource.google/fuchsia/fuchsia/+/main:src/recovery/lib/recovery-ui/src/keyboard.rs;l=111;drc=e1ed8a47e77b0ea1d6f83b93830c4e975a8a6089 (from Type inference failure for f32 #123824 (comment))
• taffy: https://github.com/DioxusLabs/taffy/blob/f1e4edab96ee13f7d1fbc2536ac31633b0e620d6/src/style_helpers.rs#L58 (from Type inference failure for f32 #123824 (comment))
• contour-rs: https://github.com/mthh/contour-rs/blob/08c1d83a1461aa19543ed402d23908eb55234fd1/src/lib.rs#L488-L491 (from Fix overflow when using large raster sizes mthh/contour-rs#13 (comment))
• Bevy: f32::from(<untyped float>) inference with f16 and f128 #123831 (comment)
• egui: the trait bound f32: From<f64> is not satisfied error on nightly emilk/egui#4352

@rustbot label +T-lang +T-libs +A-edition-2024 +F-f16_and_f128

[tgross35]

@rustbot label -needs-triage

[compiler-errors]

There's no way we can provide an impl conditional on edition, since those are always global and can't really be conditional based on the way that the trait solver works.

The way that this worked for into_iter() and arrays is that it only affected dot-method syntax, and we just skipped over the candidate for [T; N] when we had [].into_iter() -- I expect this to have to be implemented differently for From::from and/or f32::from, since there's only one candidate being assembled here <f32 as From<?0>>::from where the choice of that ?0 type variable is the thing that's becoming ambiguous here.

We still may be able to hack around this, but I would strongly urge first doing the analysis of the fallout from breaking inference here, since any hacks that we need to introduce need to exist for approximately forever, which is a long time.

[tgross35]

Too bad, but that makes enough sense. I guess it would be interesting to see crater results, though the fact that this was discovered within 24 hours of merge makes me think there could be quite a lot of codebases relying on this somewhere...

@rustbot label -A-edition-2024

[tgross35]

Crater run at #122470 (comment)

[workingjubilee]

Some languages give literals their own special type for making from-literal conversions more tractable to steer in the type system.

[nicoburns]

Some kind of improvement to type inference such that it can handle this case would seem ideal. Perhaps even a lang feature to allow user code to guide the inference process.

From a library author's position this change is awkward because it is not necessarily possible to fix it without making a semver-breaking update. But it also seems non-great if these API additions are blocked indefinitely.