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

Tracking Issue for maybe_uninit_array_assume_init #80908

Closed
1 of 6 tasks
joboet opened this issue Jan 11, 2021 · 13 comments
Closed
1 of 6 tasks

Tracking Issue for maybe_uninit_array_assume_init #80908

joboet opened this issue Jan 11, 2021 · 13 comments
Labels
C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@joboet
Copy link
Contributor

joboet commented Jan 11, 2021

Feature gate: #![feature(maybe_uninit_array_assume_init)]

This is a tracking issue for MaybeUninit::array_assume_init.

Public API

// core::mem::maybe_uninit

impl<T> MaybeUninit<T> {
    pub unsafe fn array_assume_init<const N: usize>(array: [Self; N]) -> [T; N];
}

Steps / History

Unresolved Questions

  • Should this be a const function?
  • Should this be a method of array?
  • Should this method be replaced by a conversion method from [MaybeUninit<T>; N] to MaybeUninit<[T; N]> (see comment).
@joboet joboet added the C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. label Jan 11, 2021
@joboet

This comment has been minimized.

@rustbot rustbot added the T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. label Jan 11, 2021
@hellow554

This comment has been minimized.

@joboet

This comment has been minimized.

@hellow554

This comment has been minimized.

JohnTitor added a commit to JohnTitor/rust that referenced this issue Jan 26, 2021
…ertion, r=m-ou-se

Fix assertion in `MaybeUninit::array_assume_init()` for zero-length arrays

That assertion has a false positive ([playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=63922b8c897b04112adcdf346deb1d0e)):
```rust
#![feature(maybe_uninit_array_assume_init)]

use std::mem::MaybeUninit;

enum Uninhabited {}

fn main() {
    unsafe {
        // thread 'main' panicked at 'attempted to instantiate uninhabited type `Uninhabited`'
        MaybeUninit::<Uninhabited>::array_assume_init([]);
    }
}
```
*Previously reported in rust-lang#80600 (comment)

This PR makes it ignore zero-length arrays.

cc rust-lang#80908
@bstrie
Copy link
Contributor

bstrie commented Jan 31, 2021

The documentation for this item suggests that it should be used with another unstable API, MaybeUninit::uninit_array. However that API is not contained under this feature flag, and furthermore I can't find a tracking issue for it. Should we use this issue to track that one as well?

@cole-miller
Copy link

Fwiw, this function is now used by hashbrown (nightly crate feature only, introduced in rust-lang/hashbrown#239). I'd love to see it stabilized soon! (Along with maybe_uninit_uninit_array.)

@the8472
Copy link
Member

the8472 commented Oct 27, 2021

A possible alternative is to have a conversion method from [MaybeUninit<T>; N] to MaybeUninit<[T; N]> and then assume_init() the latter. Then a separate array_assume_init() function isn't needed.

@joboet
Copy link
Contributor Author

joboet commented Dec 12, 2021

A possible alternative is to have a conversion method from [MaybeUninit<T>; N] to MaybeUninit<[T; N]> and then assume_init() the latter. Then a separate array_assume_init() function isn't needed.

That's a good idea! MaybeUninit::from(_).assume_init() is about the same length as MaybeUninit::array_assume_init(_) and allows for better integration with the other methods.

@Kixunil
Copy link
Contributor

Kixunil commented Feb 2, 2022

Converting in the other direction could be useful too as well as between MaybeUninit<[MaybeUninit<T>; N]> and the rest.

@clarfonthey
Copy link
Contributor

Would very much like some version of uninit_array and array_assume_init to be stable; right now there's not really a stable equivalent.

IMHO, we should at least collect the array-based issues into a single issue (likely this one) like what's already done with the slice methods in #63569.

@Raekye
Copy link
Contributor

Raekye commented Apr 14, 2022

  • Should this be a const function?

MaybeUninit::assume_init is const as of 1.59, and I'd like to see this be const as well

One issue with the conversion traits (From and Into) is that they can't be used in const contexts, so I'd like this function to exist as well

@clarfonthey
Copy link
Contributor

I filed #96097 since MaybeUninit::uninit_array didn't have a tracking issue, and linked to this one. So, stuff that doesn't specifically apply to MaybeUninit::array_assume_init and concerns uninit arrays in general can probably go there instead of here.

Also created #96099 which adds constness to this method + links everything to the new issue so people are funnelled in the same place. If you think array_assume_init should still point here, I would voice so there.

@joboet
Copy link
Contributor Author

joboet commented Apr 16, 2022

Thank you! I'll close this issue then. For future readers: please go to #96097 for further discussion of this feature.

@joboet joboet closed this as completed Apr 16, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. 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

9 participants