-
Notifications
You must be signed in to change notification settings - Fork 13.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Stabilize num_midpoint_signed
feature
#134340
Conversation
@rfcbot fcp merge |
Team member @dtolnay has proposed to merge this. The next step is review by the rest of the tagged team members: No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for info about what commands tagged team members can give me. |
@Amanieu @m-ou-se @BurntSushi could one of you take a look at the FCP above, there is only one checkbox missing. |
This comment was marked as resolved.
This comment was marked as resolved.
ab02b46
to
5914fb7
Compare
🔔 This is now entering its final comment period, as per the review above. 🔔 |
The final comment period, with a disposition to merge, as per the review above, is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. This will be merged soon. |
With the FCP having completed, |
…kingjubilee Rollup of 12 pull requests Successful merges: - rust-lang#131651 (Create a generic AVR target: avr-none) - rust-lang#134340 (Stabilize `num_midpoint_signed` feature) - rust-lang#136473 (infer linker flavor by linker name if it's sufficiently specific) - rust-lang#136608 (Pass through of target features to llvm-bitcode-linker and handling them) - rust-lang#136985 (Do not ignore uninhabited types for function-call ABI purposes. (Remove BackendRepr::Uninhabited)) - rust-lang#137270 (Fix `*-win7-windows-msvc` target since 26eeac1) - rust-lang#137312 (Update references to cc_detect.rs) - rust-lang#137318 (Workaround Cranelift not yet properly supporting vectors smaller than 128bit) - rust-lang#137322 (Update docs for default features of wasm targets) - rust-lang#137324 (Make x86 QNX target name consistent with other Rust targets) - rust-lang#137338 (skip submodule updating logics on tarballs) - rust-lang#137340 (Add a notice about missing GCC sources into source tarballs) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of rust-lang#134340 - Urgau:stabilize-num_midpoint_signed, r=scottmcm Stabilize `num_midpoint_signed` feature This PR proposes that we stabilize the signed variants of [`iN::midpoint`](rust-lang#110840 (comment)), the operation is equivalent to doing `(a + b) / 2` in a sufficiently large number. The stabilized API surface would be: ```rust /// Calculates the middle point of `self` and `rhs`. /// /// `midpoint(a, b)` is `(a + b) / 2` as if it were performed in a /// sufficiently-large signed integer type. This implies that the result is /// always rounded towards zero and that no overflow will ever occur. impl i{8,16,32,64,128,size} { pub const fn midpoint(self, rhs: Self) -> Self; } ``` T-libs-api previously stabilized the unsigned (and float) variants in rust-lang#131784, the signed variants were left out because of the rounding that should be used in case of negative midpoint. This stabilization proposal proposes that we round towards zero because: - it makes the obvious `(a + b) / 2` in a sufficiently-large number always true - using another rounding for the positive result would be inconsistent with the unsigned variants - it makes `midpoint(-a, -b)` == `-midpoint(a, b)` always true - it is consistent with `midpoint(a as f64, b as f64) as i64` - it makes it possible to always suggest `midpoint` as a replacement for `(a + b) / 2` expressions *(which we may want to do as a future work given the 21.2k hits on [GitHub Search](https://github.com/search?q=lang%3Arust+%2F%5C%28%5Ba-zA-Z_%5D*+%5C%2B+%5Ba-zA-Z_%5D*%5C%29+%5C%2F+2%2F&type=code&p=1))* `@scottmcm` mentioned a drawback in rust-lang#132191 (comment): > I'm torn, because rounding towards zero makes it "wider" than other values, which `>> 1` avoids -- `(a + b) >> 1` has the nice behaviour that `midpoint(a, b) + 2 == midpoint(a + 2, b + 2)`. > > But I guess overall sticking with `(a + b) / 2` makes sense as well, and I do like the negation property 🤷 Which I think is outweigh by the advantages cited above. Closes rust-lang#110840 cc `@rust-lang/libs-api` cc `@scottmcm` r? `@dtolnay`
This PR proposes that we stabilize the signed variants of
iN::midpoint
, the operation is equivalent to doing(a + b) / 2
in a sufficiently large number.The stabilized API surface would be:
T-libs-api previously stabilized the unsigned (and float) variants in #131784, the signed variants were left out because of the rounding that should be used in case of negative midpoint.
This stabilization proposal proposes that we round towards zero because:
(a + b) / 2
in a sufficiently-large number always truemidpoint(-a, -b)
==-midpoint(a, b)
always truemidpoint(a as f64, b as f64) as i64
midpoint
as a replacement for(a + b) / 2
expressions (which we may want to do as a future work given the 21.2k hits on GitHub Search)@scottmcm mentioned a drawback in #132191 (comment):
Which I think is outweigh by the advantages cited above.
Closes #110840
cc @rust-lang/libs-api
cc @scottmcm
r? @dtolnay