-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Conversation
Hey! It looks like you've submitted a new PR for the library teams! If this PR contains changes to any Examples of
|
c0b8cd3
to
a3a790d
Compare
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. |
I'm hoping that we can just stabilize |
☔ The latest upstream changes (presumably #107634) made this pull request unmergeable. Please resolve the merge conflicts. |
Hello @scottmcm! Just wanna let you know that this PR has a merge conflict :) |
Ping from triage: I'm closing this due to inactivity, Please reopen when you are ready to continue with this. @rustbot label: +S-inactive |
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
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