Remove MaybeUninit::uninit_array() and replace it with inline const blocks.

[kpreid]

[This PR originally contained the changes in #125995 too. See edit history for the original PR description.]

The documentation of MaybeUninit::uninit_array() says:

Note: in a future Rust version this method may become unnecessary when Rust allows inline const expressions. The example below could then use let mut buf = [const { MaybeUninit::<u8>::uninit() }; 32];.

The PR adding it also said: #65580 (comment)

if it’s stabilized soon enough maybe it’s not worth having a standard library method that will be replaceable with let buffer = [MaybeUninit::<T>::uninit(); $N];

That time has come to pass — inline const expressions are stable — so MaybeUninit::uninit_array() is now unnecessary. The only remaining question is whether it is an important enough convenience to keep it around.

I believe it is net good to remove this function, on the principle that it is better to compose two orthogonal features (MaybeUninit and array construction) than to have a specific function for the specific combination, now that that is possible.

[rustbot]

r? @Nilstrieb

rustbot has assigned @Nilstrieb.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[ChayimFriedman2]

I still prefer MaybeUninit::uninit_array() to [const { MaybeUninit::uninit() }; N], it's shorter and more readable IMHO.

[workingjubilee]

The examples and the compiler code should probably still prefer the stable option.

Technically the compared-against example was [MaybeUninit::uninit(); N], which implies that the array initializer is a const context.

[Noratrieb]

this fell down into the "i hope to get to this eventually but will probably never lol" part of my notification queue and i forgot to look at it again, sorry.
you have my approval for the first two commits, but I'd like a libs-api opinion on the last one. you can split out the first two into a new PR and i'll approve that, or you can keep them all like this if you're okay with letting the first two wait longer (as it will probably take a bit).
r? libs-api

[kpreid]

Split out the first two parts into #125995. I'll re-summarize this PR once that's merged.

[bors]

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

[kpreid]

This PR now consists solely of removing MaybeUninit::uninit_array().

[dtolnay]

Thanks!

I am attempting to start a T-libs-api FCP for this in #96097 (comment).

https://rust-lang.zulipchat.com/#narrow/stream/242791-t-infra/topic/rfcbot.20asleep

[Amanieu]

We discussed this in the @rust-lang/libs-api meeting today. We are happy to remove uninit_array, but would like to keep it unstable to see if there is demand for a shorter-to-write version of the const block variant.

As such we would like to:

• Point people to the const block syntax in the docs for uninit_array.
• If after 2-3 releases of having stabilized const blocks nobody has commented in the tracking issue for uninit_array then just remove it.

[kpreid]

@Amanieu What should be done with the usage of uninit_array()? In other words, should this PR be just closed, or should it be trimmed down to only remove usage and not remove the function?

[bors]

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

[clarfonthey]

Presumably the answer would be deprecating the method and pointing to the tracking issue to get more feedback?

I still think that the correct answer would be the ability to index into MaybeUninit<[T; N]> directly to get MaybeUninit<T> references, but every time I bring this up folks don't seem to keen on the idea.

[dtolnay]

What should be done with the usage of uninit_array()? In other words, should this PR be just closed, or should it be trimmed down to only remove usage and not remove the function?

I would like to accept all the other changes in this PR other than the deletion of the function. I think we should go ahead and use our own recommended replacement in rustc that we are recommending everyone outside rustc to use.

I would also accept a #[deprecated = "..."] attribute on uninit_array with guidance in the deprecation message to use [MaybeUninit::uninit(); N] or [const { MaybeUninit::uninit() }; N] instead.

I still think that the correct answer would be the ability to index into MaybeUninit<[T; N]> directly to get MaybeUninit<T> references, but every time I bring this up folks don't seem too keen on the idea.

@clarfonthey do you have a link to this getting shot down? I am on board with this Index and IndexMut impl being added.

[clarfonthey]

I don't have any specific examples of an Index impl being shot down, although I can go and take a look later today to find some of the specific discussions I've been thinking of.

Most of them concern specifically impls for MaybeUninit<[T]> and the existence of that type in general, which has mostly been met with apprehension. It would require dedicated compiler support to make that work, since unsized unions aren't a thing right now.

Of course, for arrays, that restriction doesn't apply.

[kpreid]

I would like to accept all the other changes in this PR other than the deletion of the function.

Updated.

[kpreid]

@rustbot ready

@rustbot label -O-windows

[dtolnay]

@bors r+

[bors]

📌 Commit 13fca73 has been approved by dtolnay

It is now in the queue for this repository.