Fallback {float} to f32 when f32: From<{float}> and add impl From<f16> for f32

[beetrees]

View all comments

Currently, the following code compiles:

fn foo<T: Into<f32>>(_: T) {}

fn main() {
    foo(1.0);
}

This is because the only From<{float}> impl for f32 is currently From<f32>. However, once impl From<f16> for f32 is added this is no longer the case. This would cause the float literal to fallback to f64, subsequently causing a type error as f32 does not implement From<f64>. While this kind of change to type inference isn't technically a breaking change according to Rust's breaking change policy, the previous attempt to add impl From<f16> for f32 was removed #123830 due to the large number of crates affected (by my count, there were root regressions in 42 crates and 52 GitHub repos, not including duplicates). This PR solves this problem by using f32 as the fallback type for {float} when there is a trait predicate of f32: From<{float}>. This allows adding impl From<f16> for f32 without affecting the code that currently compiles (such as the example above; this PR shouldn't affect what is possible on stable).

This PR also allows adding a future-incompatibility warning for the fallback to f32 (currently implemented in the third commit) if the lang team wants one (allowing the f32 fallback to be removed in the future); alternatively this could be expanded in the future into something more general like @tgross35 suggested in #123831 (comment). I think it would be also possible to disallow the f32 fallback in a future edition.

As expected, a crater check showed no non-spurious regressions.

For reference, I've based the implementation loosely on the existing calculate_diverging_fallback. This first commit adds the f32 fallback, the second adds impl From<f16> for f32, and the third adds a FCW lint for the f32 fallback. I think this falls under the types team, so
r? types

Fixes: #123831
Tracking issue: #116909

@rustbot label +T-lang +T-types +T-libs-api +F-f16_and_f128

To decide on whether a future-incompatibility warning is desired or otherwise (see above):
@rustbot label +I-lang-nominated

[rustbot]

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

[compiler-errors]

@bors try

[bors]

⌛ Trying commit f4cb5a7 with merge 3ec2a77...

[bors]

☀️ Try build successful - checks-actions
Build commit: 3ec2a77 (3ec2a775459d36c7d90654e47c56ff7bb0d542ab)

[compiler-errors]

@craterbot check

[craterbot]

👌 Experiment pr-139087 created and queued.
🤖 Automatically detected try build 3ec2a77
🔍 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-139087 is now running

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

[craterbot]

🚨 Report generation of pr-139087 failed: timed out waiting for connection
🛠️ If the error is fixed use the retry-report command.

🆘 Can someone from the infra team check in on this? @rust-lang/infra
ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

[compiler-errors]

@craterbot retry-report

[craterbot]

🛠️ Generation of the report for pr-139087 queued again.

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

[craterbot]

🎉 Experiment pr-139087 is completed!
📊 9 regressed and 2 fixed (605729 total)
📰 Open the full report.

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

[beetrees]

I've opened a PR to run Crater to measure the impact of the trait impl and FCW at #142723.

[bors]

☔ The latest upstream changes (presumably #145423) made this pull request unmergeable. Please resolve the merge conflicts.

[joshtriplett]

There seems to be a bit of a split of opinion between "add a FCW and eventually remove the f32 fallback" and "don't add a FCW and expand the fallback so that it works for all literals constrained by From<{float}> for fN or From<{integer}> for iN/uN". I'm guessing this needs to be nominated lang team and/or types team discussion to decide which direction to head in?

Yes.

[jackh726]

I'm going to nominate this for T-types. I think we should have a meeting and discuss this at some point - I'm not sure if Niko still has impl concerns, but I still have complexity concerns. These could be easily dismissed, but seems useful to just have a sync discussion about this.

[folkertdev]

Alternatively, adding the impl From<f16> for f32 could be delayed until after stabilization.

The absence of the From impl is mildly annoying, but an as cast works just as well. I don't think any doors are closed by first stabilizing the type and later adding the impl.

In light of the stabilizing f16 we'd like to unblock stabilizing the f16 type.

[folkertdev]

@traviscross This was discussed in the lang meeting https://hackmd.io/FZR0FoQ4RkC4G3i-dKiyzg#Fallback-float-to-f32-when-f32-Fromltfloatgt-and-add-impl-Fromltf16gt-for-f32-rust139087, however I'm not exactly sure where you ended up.

Looks like you want to see a FCW lint? What would that lint on exactly, just any use of From<{float}>?

[traviscross]

We talked about this in the lang call. We're interested in unblocking the stabilization of f16. At the same time, some had reservations about doing that without some plan for being able to add this impl in a finite amount of time.

The option we discussed in the meeting went as follows:

If we could add an FCW against reliance on the fallback behavior when that fallback would be a problem for adding this impl (and it's OK if it approximates on this), then we can move maintained code off of this reliance. Then, after some time, we can take the minor (in an RFC 1105 sense) breakage due to adding this impl.

(This plan uses our normal tools for evolving the language and doesn't require us to speculate about future features. We're doing something similar to this for stabilizing the never type.)

Such a plan would give us confidence that we can likely add the impl in a finite amount of time, and that confidence would give us confidence to ship f16 today.

@folkertdev, what do you think? Is such a lint feasible? What would you propose in terms of how it could be best targeted at this problem?

[folkertdev]

@traviscross this PR already includes a FCW, @beetrees did all of the hard work already. I think this can be extracted (needs an update given all of the merge conflicts) and then that should do?

At least reading through the comments the T-types folks don't seem to have major issues with the approach here, though we'll see if anything else pops up.

note to self: I like the example from the issue better #123824

[folkertdev]

Ah, the lint here only works when adding the additional f16 instance (creating the ambiguity).

I'll push the rebased version anyway in case it's helpful, but a different approach to trigger the lint is needed and my knowledge of the type checker is insufficient to know what that would look like, so I'll need some help there.

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[rust-log-analyzer]

The job tidy failed! Check out the build log: (web) (plain enhanced) (plain)

Click to see the possible cause of the failure (guessed by this bot)

     ╭▸ compiler/rustc_lint_defs/src/builtin.rs:5644:22
     │
5644 │     /// longer guide inferrence for the type of the floating point literal. The default fallback for
     ╰╴                     ━━━━━━━━━━
error: `occurences` should be `occurrences`
    ╭▸ compiler/rustc_hir_typeck/src/fn_ctxt/inspect_obligations.rs:227:42
    │
227 │         // 3 is more than enough for all occurences in practice (a.k.a. `Into`).
    ╰╴                                         ━━━━━━━━━━
rerun tidy with `--extra-checks=spellcheck --bless` to fix typos
tidy [extra_checks:spellcheck]: checks with external tool 'typos' failed
tidy [extra_checks:spellcheck]: FAIL
yarn install v1.22.22
warning package.json: No license field
warning ../../package.json: License should be a valid SPDX license expression
warning No license field
[1/4] Resolving packages...
---
linting javascript files
Running eslint on rustdoc JS files
info: ES-Check: there were no ES version matching errors!  🎉
typechecking javascript files
tidy: The following check failed: extra_checks:spellcheck
Command `/checkout/obj/build/x86_64-unknown-linux-gnu/stage1-tools-bin/rust-tidy --root-path=/checkout --cargo-path=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo --output-dir=/checkout/obj/build --concurrency=4 --npm-path=/node/bin/yarn --ci=true --extra-checks=py,cpp,js,spellcheck` failed with exit code 1
Created at: src/bootstrap/src/core/build_steps/tool.rs:1618:23
Executed at: src/bootstrap/src/core/build_steps/test.rs:1387:29

Command has failed. Rerun with -v to see more details.
Bootstrap failed while executing `test src/tools/tidy tidyselftest --extra-checks=py,cpp,js,spellcheck`
Build completed unsuccessfully in 0:03:06
  local time: Sun Mar 15 12:15:49 UTC 2026
  network time: Sun, 15 Mar 2026 12:15:49 GMT
##[error]Process completed with exit code 1.