Rename MaybeUninit to MaybeUninitialized

[shepmaster]

Proposal to finalize the name as MaybeUninit#56138 (comment) -- as in, the FCP is to close this PR.

rfcbot comment is here

---

Changed via:

git ls-files -z | xargs -0 -L1 gsed --in-place 's@\bMaybeUninit\b@MaybeUninitialized@'

Checked via:

rg -uuu '\bMaybeUninit\b'

[shepmaster]

r? @RalfJung

[shepmaster]

I know this is racing your other PR, so you get to review!

[RalfJung]

Fine for me. @rust-lang/libs @rust-lang/lang any objections?

[withoutboats]

What's the motivation for this change?

[shepmaster]

Wrds r btr thn abbrs.

[shepmaster]

For full context, if you start reading the comments here, there's an overwhelming consensus to add more words into the method names of this type to better indicate their unsafety and usage concerns.

Since the point of all of those words is to force the user to think more about careful usage of this type, making sure that the type's name itself is unambiguous is a good start.

[withoutboats]

What could Uninit be ambiguous with?

[withoutboats]

The specific example there is into_inner, which is a common name for a safe method that unwraps a newtype into its inner type, which isn't the functionality of this method. Its not about adding more words, its about not using a name that encourages misuse. I don't see a similar motivation here; abbreviations in themselves are quite common in the standard library and not against its style guidelines: Iter, Buf, Rc, Arc, Cow, etc (edit: ptr, mem, fmt, println, ...)

[shepmaster]

Ok

[SimonSapin]

There is also a precedent in the standard library to avoid sometimes-well-established abbreviations: copy_from_nonoverlapping, set_permissions, etc.

[RalfJung]

I actually think we should do this and would propose reopening the PR. We usually avoid abbreviations unless they are extremely widely used (like pretty much all of @withoutboats' examples).

Another example is compare_and_swap.

[varkor]

We usually avoid abbreviations unless they are extremely widely used (like pretty much all of @withoutboats' examples).

I think some of the examples like Iter and Buf are not "extremely widely used" (at least compared to Uninit), but are similarly unambiguous. (Personally, I prefer shorter names when unambiguous.)

[RalfJung]

Note that this replaces mem::uninitialized, so the precedent here clearly is to not abbreviate.

[nikic]

mem::uninit() is ambiguous in that it can abbreviate both uninitialized (a state) and uninitialize (and operation). The ambiguity does not exist with MaybeUnint, which clearly refers to a state.

[joshtriplett]

I certainly don't want to see this used often, but at the same time, this seems like unnecessary syntactic salt.

[Centril]

My main gripe is with into_inner which is innocent looking and misleading; that's where the actual unsafety lies and that's where I think adjustment is necessary.

I don't think a lot is gained by lengthening the name of the type here but at the same time I don't feel the need for unsafe code to be overly ergonomic to write. So my reaction to this PR is pretty neutral. I'm not for nor against it -- if you can convince everyone else then I'm sold. :)

[WiSaGaN]

“maybe uninitialized" is pretty commonly used term in system programming: https://stackoverflow.com/questions/14132898/gcc-wuninitialized-wmaybe-uninitialized-issues

System programmers that are used to the term will make more effort to recognize "MaybeUninit" than the more commonly used fully spelled out version. It is also easier to relate "MaybeUninitialized" to the original "mem::uninitialized" method.

[bors]

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

[pnkfelix]

@rfcbot concern i-am-un-maybe-init

@Centrilclaimed that MaybeUninit is equivalent to MaybeInit. I disagree. Yes, I can see that the two phrases indicate the same underlying semantics: The data here may or may not be initialized. I argue that it is important to stress the "un" in "uninitialized", which justifies the inclusion of those two additional characters. The benefit is to stimulate all those neural pathways associated with "uninitialized" (=> here be dragons).

I'm speaking about the benefit for human authors and code reviewers, especially those who are perhaps looking over something quickly and might not catch an occurrence of "Maybe" (even when next to "Init") but would catch "Uninit".

I don't think there is a net win from renaming replacing MaybeUninit with MaybeInit.

---

(I don't have an opinion about the original proposal to lengthen the name to MaybeUninitialized. I would have a similar objection to a rename to MaybeInitialized.)

[scottjmaddox]

pnkfelix's argument seems reasonable to me. There isn't really much of an advantage in renaming to MaybeInit, anyways, other than being ever so slightly easier to type.

[joshtriplett]

@pnkfelix I agree entirely, and I have the same objection. This not only doesn't seem worth the change, it seems less clear.

[Centril]

@pnkfelix

I'm speaking about the benefit for human authors and code reviewers, especially those who are perhaps looking over something quickly and might not catch an occurrence of "Maybe" (even when next to "Init") but would catch "Uninit".

This is persuasive. Therefore:

@rfcbot cancel

[rfcbot]

@Centril proposal cancelled.

[Centril]

I propose that we finalize the name of the type as MaybeUninit (note the Un); The proposal is merely for the type's name and not for stabilization of the type itself.

@rfcbot merge

(EDIT: this is a bit weird.. we're "merging" but this means that the PR itself will be closed...)

[rfcbot]

Team member @Centril has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Centril
• @Kimundi
• @SimonSapin
• @alexcrichton
• @aturon
• @cramertj
• @dtolnay
• @eddyb
• @joshtriplett
• @nikomatsakis
• @pnkfelix
• @scottmcm
• @sfackler
• @withoutboats

No concerns currently listed.

Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[shepmaster]

especially those who are perhaps looking over something quickly and might not catch an occurrence of "Maybe" (even when next to "Init") but would catch "Uninit".

I don't know enough HCI to refute this claim, but it seems odd to expect people to read the middle of a word but not the beginning. Similarly, it seems odd that people are more likely to catch "Uninit" than they would be "Uninitialized".

[nikomatsakis]

While I checked my name, I would like to note for the record that I prefer the name Uninit -- I feel the maybe is implied. But I don't really care enough to argue strongly one way or the other. =)

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[tesuji]

I am not a native English speaker, and have not used much unsafe code. So every time I see MaybeUninit, I read it like maybe uni-nit. That's so weird!

[gnzlbg]

I find the mixture of abbreviations with long spellings in the API weird: MaybeUninit vs ::into_initialized. If we want to keep the abbreviation in the name (use MaybeUninit or Uninit - I prefer Uninit since the maybe is implied), then it might be worth it to also use the abbreviation in the other apis, like ::into_init(), for consistency.

Without consistency, unless I use this API all-day every-day I pretty much have to guess whenever I need it. I wish the standard library would have clear guidelines about this instead of each API doing its own thing, it would save us a lot of time (bikeshedding, context-switching to the docs because rustc does not suggest the right thing, etc.).

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

[RalfJung]

So, uh, I guess we just close this PR now?

[Centril]

Indeed we should; Thank you @shepmaster for your work & proposal.