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.

[BD103]

Can the link to the Taffy regression be updated to https://github.com/DioxusLabs/taffy/blob/f1e4edab96ee13f7d1fbc2536ac31633b0e620d6/src/style_helpers.rs#L58, before it was fixed in DioxusLabs/taffy@9f27870?

[BD103]

I'm also getting the same warnings for this line, this line, this line, this line, and these lines.

Most of them are related to casting a tuple ({float}, {float}) / array [{float}; 2] to our custom WindowResolution struct. The last one is different, though, because it runs into Taffy's fn foo<T: Into<f32>>(x: T) functions.

I hope this helps :)

[tgross35]

Crater finished https://crater-reports.s3.amazonaws.com/pr-122470/index.html

[compiler-errors]

Hm -- looks like a lot of these are due to Into<f32> bounds (e.g. in arguments) and not due to method dispatch.

As I stated above, impls need to apply globally, so it's gonna be a bit harder to fix this (if possible at all, without hacking out something that I'd be afraid of having to support in perpetuity).

[tgross35]

Yeah, I would rather not have this impl than have something specific and hacky.

How feasible would it be for untyped literals to select their type based on the bound? As in, if there is a requirement for impl Into<T> and an unsuffixed literal could represent T, then choose that rather than falling back to the default f64/i32. Which I think would resolve most of the failures here, in addition to making something like this work:

fn foo(a: impl Into<u64>) {}

fn main() {
    foo(100);
}