Stabilize float::to_int_unchecked

[Mark-Simulacrum]

This renames and stabilizes unsafe floating point to integer casts, which are intended to be the substitute for the currently unsound as behavior, once that changes to safe-but-slower saturating casts. As such, I believe this also likely unblocks #10184 (our oldest I-unsound issue!), as once this rolls out to stable it would be far easier IMO to change the behavior of as to be safe by default.

This does not stabilize the trait or the associated method, as they are deemed internal implementation details (and consumers should not, generally, want to expose them, as in practice all callers likely know statically/without generics what the return type is).

Closes #67058

[rust-highfive]

r? @cramertj

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

[Mark-Simulacrum]

I am uncertain if we want another round of FCP, but I think likely no. To confirm, r? @SimonSapin

[Amanieu]

I think we're just waiting on the FCP in #67058.

[SimonSapin]

I’d prefer if the trait method name and the intrinsic name were kept consistent (perhaps with float_ prepended for the intrinsic)

[Mark-Simulacrum]

Updated the intrinsic to float_to_int_unchecked as well.

[SimonSapin]

r=me when the FCP finishes

[bors]

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

[SimonSapin]

@bors r+ #67058 (comment)

[bors]

📌 Commit 5614721 has been approved by SimonSapin

[CodesInChaos]

I would have preferred having the word trunc(ate) in the method name, but it looks like it's too late to change that now.

[SimonSapin]

@CodesInChaos In my opinion it depends what other conversion methods we end up adding to floats. In https://internals.rust-lang.org/t/pre-rfc-add-explicitly-named-numeric-conversion-apis/11395 (that I still need to finish writing up into a proper RFC) I proposed adding various conversion methods that could be preferred over as for their more explicit names and for including alternative semantics. For example the proposed (#10184) behavior for float-to-int as is saturation, but wrapping might make sense for some users.

Now with truncation here I assume you mean as opposed to other rounding modes such as round-to-nearest. I think having this be part of the name would be important if we eventually add something like round_to_int_unchecked. Could that be implemented in any way that’s significantly better than composing with the existing .round() method? If not, then I think it’s not worth having a dedicated method and we can instead suggest that pattern in docs. In that case, I don’t feel strongly about having the rounding mode in the method name.

If you do feel strongly, it’s not entirely too late. We have precedent for making changes to something after a stabilization PR has landed, before it reaches the Stable release channel. Consider filing a new issue (a merged PR is "resolved" and so not a great place for new discussion) with a concrete proposal (exact name) and some arguments. Not as formal as an RFC, but in the same spirit. @-mention me in it.

[CodesInChaos]

@SimonSapin I'd prefer the more descriptive name, but I don't feel strongly about this case, since truncation is the default in most languages and thus what people expect.