-
Notifications
You must be signed in to change notification settings - Fork 13.3k
What if we just add <[MaybeUninit<T>; N]>::assume_init
directly?
#104475
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
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