Skip to content
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

Merged
merged 1 commit into from
Feb 21, 2025

Conversation

Urgau
Copy link
Member

@Urgau Urgau commented Dec 15, 2024

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:

/// 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 #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)

@scottmcm mentioned a drawback in #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 #110840
cc @rust-lang/libs-api
cc @scottmcm
r? @dtolnay

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Dec 15, 2024
@Urgau Urgau mentioned this pull request Dec 15, 2024
7 tasks
@Urgau Urgau added T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. I-libs-api-nominated Nominated for discussion during a libs-api team meeting. and removed T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Dec 15, 2024
@dtolnay
Copy link
Member

dtolnay commented Dec 15, 2024

@rfcbot fcp merge

@rfcbot
Copy link

rfcbot commented Dec 15, 2024

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.

@rfcbot rfcbot added proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. labels Dec 15, 2024
@dtolnay dtolnay removed the I-libs-api-nominated Nominated for discussion during a libs-api team meeting. label Dec 15, 2024
@Urgau
Copy link
Member Author

Urgau commented Jan 20, 2025

@Amanieu @m-ou-se @BurntSushi could one of you take a look at the FCP above, there is only one checkbox missing.

@Urgau Urgau added S-waiting-on-team Status: Awaiting decision from the relevant subteam (see the T-<team> label). and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jan 21, 2025
@bors

This comment was marked as resolved.

@Urgau Urgau force-pushed the stabilize-num_midpoint_signed branch from ab02b46 to 5914fb7 Compare January 27, 2025 17:22
@rfcbot rfcbot added final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. and removed proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. labels Feb 10, 2025
@rfcbot
Copy link

rfcbot commented Feb 10, 2025

🔔 This is now entering its final comment period, as per the review above. 🔔

@Amanieu Amanieu added S-waiting-on-fcp Status: PR is in FCP and is awaiting for FCP to complete. and removed S-waiting-on-team Status: Awaiting decision from the relevant subteam (see the T-<team> label). labels Feb 11, 2025
@rfcbot rfcbot added finished-final-comment-period The final comment period is finished for this PR / Issue. to-announce Announce this issue on triage meeting and removed final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. labels Feb 20, 2025
@rfcbot
Copy link

rfcbot commented Feb 20, 2025

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.

@scottmcm
Copy link
Member

With the FCP having completed,
@bors r+ rollup=always

@bors
Copy link
Contributor

bors commented Feb 20, 2025

📌 Commit 5914fb7 has been approved by scottmcm

It is now in the queue for this repository.

@bors bors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Feb 20, 2025
bors added a commit to rust-lang-ci/rust that referenced this pull request Feb 21, 2025
…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
@bors bors merged commit 480a72d into rust-lang:master Feb 21, 2025
6 checks passed
@rustbot rustbot added this to the 1.87.0 milestone Feb 21, 2025
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Feb 21, 2025
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`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. finished-final-comment-period The final comment period is finished for this PR / Issue. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. S-waiting-on-fcp Status: PR is in FCP and is awaiting for FCP to complete. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. to-announce Announce this issue on triage meeting
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Tracking Issue for num_midpoint
7 participants