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

What if we just add <[MaybeUninit<T>; N]>::assume_init directly? #104475

Closed
wants to merge 1 commit into from

Conversation

scottmcm
Copy link
Member

I recall (though can't find where) libs-api being unsatisfied with the transpose approach for this, so I figured I'd toss out this as another alternative.

Now that we don't need lang item hacks to add inherent impl blocks for built-in types, we can just add

impl<T, const N: usize> [MaybeUninit<T>; N] {
    pub const unsafe fn assume_init(self) -> [T; N];
}

That seems pretty reasonable -- the odds of another meaning for assume_init on generic overlays that might overlap feel low to me, and another specific meaning of it for arrays of a different type would still be possible.

If this is worth doing, I can add analogous things to &[MaybeUninit<T>] and &mut [MaybeUninit<T>] too.

cc #96097
r? @m-ou-se

@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 Nov 16, 2022
@rustbot
Copy link
Collaborator

rustbot commented Nov 16, 2022

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with @rustbot label +T-libs-api -T-libs to tag it appropriately. If this PR contains changes to any unstable APIs please edit the PR description to add a link to the relevant API Change Proposal or create one if you haven't already. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

  • Stabilizing library features
  • Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
  • Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
  • Changing public documentation in ways that create new stability guarantees
  • Changing observable runtime behavior of library APIs

@scottmcm scottmcm added the T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. label Nov 16, 2022
@SUPERCILEX
Copy link
Contributor

Can you post the rationale on rust-lang/libs-team#122? The original reason for transpose was to also let you index into the array which this PR doesn't solve in the general case. I wonder if we should commit to having slice methods and offer an array to slice conversion and then let you do index operations with the slice instead of the array.

@scottmcm
Copy link
Member Author

I'm hoping that we can just stabilize inline_const (I've proposed it). At that point, [const { MaybeUninit::uninit() }; N] works, which makes the MaybeUninit::uninit().transpose() much less needed, and thus I started thinking whether we could get away without the other transpose either.

@bors
Copy link
Contributor

bors commented Feb 13, 2023

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

@anden3 anden3 added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Apr 13, 2023
@anden3
Copy link
Contributor

anden3 commented Apr 13, 2023

Hello @scottmcm! Just wanna let you know that this PR has a merge conflict :)

@JohnCSimon
Copy link
Member

@scottmcm

Ping from triage: I'm closing this due to inactivity, Please reopen when you are ready to continue with this.
Note: if you are going to continue please open the PR BEFORE you push to it, else you won't be able to reopen - this is a quirk of github.
Thanks for your contribution.

@rustbot label: +S-inactive

@JohnCSimon JohnCSimon closed this Dec 17, 2023
@rustbot rustbot added the S-inactive Status: Inactive and waiting on the author. This is often applied to closed PRs. label Dec 17, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-inactive Status: Inactive and waiting on the author. This is often applied to closed PRs. S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-libs Relevant to the library team, which will review and decide on the PR/issue. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants