An additional issue: Should Vec::into_parts return a struct with pub fields rather than a tuple? Having two usize tuple elements seems a bit error prone. Alternatively it could return (NonNull<[T]>, usize).

EDIT: It could also be (NonNull<[MaybeUninit<T>]>, usize), the pointer being the storage (ptr + cap) and the usize being the length.

Just cataloguing the similar methods from rustdoc:

from_raw_parts/slice_from_raw_parts

• (*const T, usize) <-> &[T]
• (*const u8, usize) <-> str (unstable)
• (NonNull<T>, usize) <-> NonNull<[T]>

into_raw_parts/from_raw_parts

• String <-> (*mut u8, usize, usize)
• Vec<T> <-> (*mut T, usize, usize)'

from_parts/into_parts: (proposed)

• Vec<T> <-> (NonNull<T>, usize, usize)

to_raw_parts/from_raw_parts (unstable)

• *const T <-> (*const (), T::Metadata)
• NonNull<T> <-> `(NonNull<()>, T::Metadata)

I think that (NonNull<T>, usize, usize) would be a good choice due to the analogy to from_raw_parts/into_raw_parts, but that maybe it should be named from_non_null_parts instead.

The only other methods in libstd that use the term "parts" are BufWriter::into_parts, returning (W, Result<Vec<u8>, WriterPanicked) and IntoInnerError::into_parts (returned by BufWriter::into_inner) which returns (Error, W). (yes, annoyingly, those are reversed.)

Would say that maybe we should not label any "parts" as canonical for now at least, since it's not clear what version would be best to use.

cc @rust-lang/opsem - is there a reason on your end to make as_non_null take a &mut instead of &? If not, we'd like to change it to & (same for rust-lang/libs-team#799). Otherwise, ready to open FCP on the other changes

Shall we stabilize these?

@rfcbot merge libs-api

@rfcbot concern as_non_null-shared-reference

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

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @the8472

Concerns:

• as_non_null-shared-reference resolved by Partially stabilize box_vec_non_null #157226 (comment)
• from_parts and into_parts naming (Partially stabilize box_vec_non_null #157226 (comment))

Once a majority of reviewers approve (and at most 2 approvals are outstanding), 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.

Which exact function is this about?

EDIT: I assume Vec::as_non_null. The outer reference doesn't affect the inner pointer in any of our current models, and I don't think it should. But we also have not conclusively ruled that out.

Though given that the returned pointer is meant to be mutable, my personal preference would be &mut self. We have repeatedly seen violations of shared reference immutability correlate with poor mutability discipline for raw pointers (const-to-mut-raw-ptr-cast is allowed but should be considered highly suspicious); I'd rather not see std proliferate patterns of that sort.

I like these. I'm concerned about the from_parts and into_parts naming though. It suggests, to me, that these are the canonical "parts" of a Vec, and it's not clear to me that's true. I think I'd rather see from_non_null_parts and into_non_null_parts. It also matches the naming convention used for the rest of the methods.

@rfcbot concern from_parts and into_parts naming

Just to confirm: T-libs-api has agreed to stabilize with the name non_null, and not nonnull, right? The meeting notes didn't mention this.

@BurntSushi The reason the Vec functions were named with parts was due to a libs-api request. Has the consensus on the best name changed since then?

@theemathas Not sure if anything has changed or if it has been discussed. That comment is from almost 2 years ago though. @joshtriplett Thoughts on the naming here?

Just to confirm: T-libs-api has agreed to stabilize with the name non_null, and not nonnull, right? The meeting notes didn't mention this.

I think we have generally agreed in the past that non-null is non_null. we kept the contracted form only for nonzero.

To resolve the & vs &mut concern, we decided in this week's libs-api meeting to defer stabilising as_non_null for now. The rest of the methods can get stabilised here as-is. cc @joshtriplett as you raised the concern

@nia-e I assume this also means:

• from_parts and into_parts are to be stabilized as-is.
• It's spelled non_null and not nonnull

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

I've updated the PR and the PR description, so Vec::as_non_null() will not be stabilized in this PR.

@BurntSushi @joshtriplett May the concerns be resolved?

I don't think my concern has been addressed. Like, from_parts/into_parts implies a level of canonical-ness that isn't obviously warranted to me. We already have from_raw_parts/into_raw_parts, so I think we should just go with from_non_null_parts/into_non_null_parts. This leaves the door open for other routines in the future, e.g., using Box<[MaybeUninit]> as noted in the OP.

I also don't think these routines are used enough to warrant the shorter name.

@rfcbot resolved as_non_null-shared-reference

I don't think we should die on the hill of naming this from_parts or from_non_null_parts, personally; if Andrew is the tie-breaking vote then we can probably tolerate a rename.

@BurntSushi I think we do want to declare that the canonical "parts" are NonNull, and thus use from_parts/into_parts. Yes, this would mean we're declaring some degree of canonicity; I think that's a feature. If we want another version, we can give it a new name, but there's a sense in which "non-null pointer" is the canonical implementation.

Wouldn't "non-null and aligned pointer" be "even more" canonical, if we can ever express that?

I guess I'm hesitant to declare anything here as canonical when there are multiple choices. If there was a bigger upside to a pithy name, then I think I'd be more open to it. But something a little more descriptive that distinguishes it from alternatives that we may add in the future seems nice.

Even in this context, (NonNull<[T]>, usize) versus (NonNull<T>, usize, usize) is technically an option. We have decided for "raw" parts, and while it's natural for non-null parts, it's not 100% clear if in the future we'll have internal parts that are more canonical, or even a "canonical" RawVec<T> part.

So, for that reason, I'm fine with putting the name into a "non-canonical" form. But, that's mostly just my 2¢ on interpreting an argument I mostly don't care about. To me, I'd rather just merge with whatever name people prefer.

@riking As currently implemented, both Box::into_non_null and Vec::into_parts currently require the default Global allocator. The PR description and the tracking issue were previously incorrect, and I've now edited them. Sorry for the discrepancy.