Stabilize float::to_int_unchecked#70487
Conversation
|
r? @cramertj (rust_highfive has picked a reviewer for you, use r? to override) |
|
I am uncertain if we want another round of FCP, but I think likely no. To confirm, r? @SimonSapin |
|
I think we're just waiting on the FCP in #67058. |
|
I’d prefer if the trait method name and the intrinsic name were kept consistent (perhaps with |
1a761df to
9947a4e
Compare
|
Updated the intrinsic to float_to_int_unchecked as well. |
SimonSapin
left a comment
There was a problem hiding this comment.
r=me when the FCP finishes
|
☔ The latest upstream changes (presumably #70525) made this pull request unmergeable. Please resolve the merge conflicts. |
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.
9947a4e to
5614721
Compare
|
📌 Commit 5614721 has been approved by |
…ts, r=SimonSapin Stabilize float::to_int_unchecked 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 rust-lang#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 rust-lang#67058
Rollup of 7 pull requests Successful merges: - rust-lang#70487 (Stabilize float::to_int_unchecked) - rust-lang#70595 (Remove unused discriminant reads from MIR bodies) - rust-lang#70691 (Improve docs in `AllocRef`) - rust-lang#70694 (Use Self over specific type in return position) - rust-lang#70700 (Expand on platform details of `include_xxx` macros) - rust-lang#70708 (Fix typo in u8::to_ascii_uppercase and u8::to_ascii_lowercase) - rust-lang#70716 (Unerase regions in infer_placeholder_type) Failed merges: r? @ghost
|
I would have preferred having the word |
|
@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 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 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. |
|
@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. |
This renames and stabilizes unsafe floating point to integer casts, which are intended to be the substitute for the currently unsound
asbehavior, 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 ofasto 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