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

Constification of BinaryHeap construction #112353

Closed
terrarier2111 opened this issue Jun 6, 2023 · 17 comments
Closed

Constification of BinaryHeap construction #112353

terrarier2111 opened this issue Jun 6, 2023 · 17 comments
Labels
A-const-fn Area: const fn foo(..) {..}. Pure functions which can be applied at compile time. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. 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. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@terrarier2111
Copy link
Contributor

Is there any reason this isn't const yet? This should only depend on vec's construction being const which it is.

@Noratrieb Noratrieb added A-const-fn Area: const fn foo(..) {..}. Pure functions which can be applied at compile time. C-feature-request Category: A feature request, i.e: not implemented / a PR. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. labels Jun 7, 2023
@est31
Copy link
Member

est31 commented Jun 8, 2023

All the other collections already have const constructors (except for the ones for which it's hard, cc #112354). So I think it makes a lot of sense to make this const as well.

There was an entire ACP for VecDequeue::new(). I don't know if one is needed for BinaryHeap as well. On the other hand, the function became instantly const-stable, there was no period where it was unstably const, see #105072.

@tsemo4917
Copy link

impl<T: Ord> BinaryHeap<T> {
    pub fn new() -> BinaryHeap<T> {
        BinaryHeap { data: vec![] }
    }
}

BinaryHeap constructor is only depends on Vec constructor, and Vec::new() has been a const function since 1.39.0.

Constification of BinaryHeap constructor will be helpful when a static variable is of the BinaryHeap type.

@dtolnay

@dtolnay
Copy link
Member

dtolnay commented Oct 19, 2023

Please send a PR.

@Coekjan
Copy link
Contributor

Coekjan commented Oct 28, 2023

I also met this issue and I am trying to address it with #117316

@est31 est31 added C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. T-libs Relevant to the library team, which will review and decide on the PR/issue. and removed T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Oct 28, 2023
workingjubilee added a commit to workingjubilee/rustc that referenced this issue Oct 28, 2023
…tor, r=dtolnay

Mark constructor of `BinaryHeap` as const fn

rust-lang#112353
workingjubilee added a commit to workingjubilee/rustc that referenced this issue Oct 29, 2023
…tor, r=dtolnay

Mark constructor of `BinaryHeap` as const fn

rust-lang#112353
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Oct 29, 2023
Rollup merge of rust-lang#117316 - Coekjan:const-binary-heap-constructor, r=dtolnay

Mark constructor of `BinaryHeap` as const fn

rust-lang#112353
@Coekjan
Copy link
Contributor

Coekjan commented Oct 29, 2023

The feature const_binary_heap_constructor was added to nightly.

Due to the unstable feature (allocator_api, issue: #32838 ), this feature is not able to be stablized now.

@est31 est31 removed the C-feature-request Category: A feature request, i.e: not implemented / a PR. label Oct 29, 2023
@LGFae
Copy link

LGFae commented May 14, 2024

Hello, @Coekjan, according to what you said in #117316, it seems that the new function could be stabilized, even without the allocator_api being stable. Any news on that front?

@Coekjan
Copy link
Contributor

Coekjan commented May 16, 2024

Hello, @Coekjan, according to what you said in #117316, it seems that the new function could be stabilized, even without the allocator_api being stable. Any news on that front?

I am a little busy this week, and I will try to see how to stablize it later.

@Coekjan
Copy link
Contributor

Coekjan commented May 17, 2024

Hello, @Coekjan, according to what you said in #117316, it seems that the new function could be stabilized, even without the allocator_api being stable. Any news on that front?

See #125211 I try to place the two functions into two different features, and stablize BinaryHeap::new.

@jhpratt jhpratt added the I-libs-api-nominated Nominated for discussion during a libs-api team meeting. label May 21, 2024
@jhpratt
Copy link
Member

jhpratt commented May 21, 2024

Nomination for discussion to stabilize. I think it's quite straightforward and has plenty of precedent.

@dtolnay
Copy link
Member

dtolnay commented May 21, 2024

@rust-lang/libs-api:
@rfcbot fcp merge

const on the already-stable constructor for BinaryHeap.

impl<T: Ord> BinaryHeap<T> {
    #[must_use]
    pub const fn new() -> Self;
}

@rfcbot
Copy link

rfcbot commented May 21, 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 May 21, 2024
@dtolnay dtolnay removed the I-libs-api-nominated Nominated for discussion during a libs-api team meeting. label May 21, 2024
@rfcbot rfcbot added the final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. label May 21, 2024
@rfcbot
Copy link

rfcbot commented May 21, 2024

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

@rfcbot rfcbot removed the proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. label May 21, 2024
@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 May 31, 2024
@rfcbot
Copy link

rfcbot commented May 31, 2024

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

scottmcm commented Jun 3, 2024

There was an entire ACP for VecDequeue::new(). I don't know if one is needed for BinaryHeap as well.

Notably, VecDeque was more interesting, because making it const implied making it non-allocating, and thus changing the existing approach for the whole type. No such complication exists for BinaryHeap.

@est31
Copy link
Member

est31 commented Jun 3, 2024

Given that #125211 has been merged, and BinaryHeap::new is const-stable now, this tracking issue is now only for const-stability of BinaryHeap::new_in.

Maybe this should be indicated at the top of the issue? Or should we make a new tracking issue?

@jhpratt
Copy link
Member

jhpratt commented Jun 4, 2024

@est31 Is there typically a tracking issue for const-stabilizing something that is itself unstable? I didn't think so, so I would actually recommend closing this.

@oli-obk oli-obk closed this as completed Jun 4, 2024
@Coekjan
Copy link
Contributor

Coekjan commented Jun 4, 2024

If it is ok, let me open a new issue to track BinaryHeap::new_in, and I will update the number of the tracking issue in the code.

@apiraino apiraino removed the to-announce Announce this issue on triage meeting label Jun 7, 2024
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Jul 24, 2024
Update tracking issue for `const_binary_heap_new_in`

This PR updates the tracking issue of `const_binary_heap_new_in` feature:
- Old issue: rust-lang#112353
- New issue: rust-lang#125961
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Jul 24, 2024
Rollup merge of rust-lang#125962 - Coekjan:const-binary-heap, r=Amanieu

Update tracking issue for `const_binary_heap_new_in`

This PR updates the tracking issue of `const_binary_heap_new_in` feature:
- Old issue: rust-lang#112353
- New issue: rust-lang#125961
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-const-fn Area: const fn foo(..) {..}. Pure functions which can be applied at compile time. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. 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. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests