Use inline const blocks to create arrays of MaybeUninit
; remove uninit_array()
.
#125082
+35
−84
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.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.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.
Delete
MaybeUninit::uninit_array()
and replace its uses with array expressions.This idea was even mentioned as an alternative when
uninit_array()
was added: AddMaybeUninit
methodsuninit_array
,slice_get_ref
,slice_get_mut
#65580 (comment)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.