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

Use inline const blocks to create arrays of MaybeUninit; remove uninit_array(). #125082

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

kpreid
Copy link
Contributor

@kpreid kpreid commented May 13, 2024

This PR contains 3 commits, arranged in order of increasing contentiousness. All of them are enabled by the fact that inline_const is now stable.

  1. Use inline const instead of unsafe to construct arrays in MaybeUninit examples.

    This should be straightforwardly good, since it eliminates now-unnecessary unsafe code in a user-facing example.

  2. Use inline const instead of unsafe to implement MaybeUninit::uninit_array().

    This is arguably giving the compiler more work to do, in exchange for eliminating just one single internal unsafe block.

  3. Delete MaybeUninit::uninit_array() and replace its uses with array expressions.

    This idea was even mentioned as an alternative when uninit_array() was added: Add MaybeUninit methods uninit_array, slice_get_ref, slice_get_mut #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];

    Const array repetition and inline const blocks are now stable (in the next release), so that circumstance has come to pass, and we no longer have this reason to want uninit_array() — unless the repeat syntax is too annoying, or the code generation is worse (on some simple test cases, it doesn't seem to be).

    I believe it is 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.

This is possible now that inline const blocks are stable; the idea was
even mentioned as an alternative when `uninit_array()` was added:
<rust-lang#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];`

Const array repetition and inline const blocks are now stable (in the
next release), so that circumstance has come to pass, and we no longer
have reason to want `uninit_array()` (unless the repeat syntax is too
annoying).
@rustbot
Copy link
Collaborator

rustbot commented May 13, 2024

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

@rustbot rustbot added O-windows Operating system: Windows S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels May 13, 2024
@ChayimFriedman2
Copy link
Contributor

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

@workingjubilee
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
O-windows Operating system: Windows S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants