Consider replacing RawVec<T> with Box<[MaybeUninit<T>]>.

[eddyb]

After #53508 lands, we could look into this. It might provide a bit more type-safety, although it could be worse to not have the capacity as a separate field.

One thing to note is that setting the "length" component of a reference/pointer to [MaybeUninit<T>] is "less unsafe" than doing so for for [T], but it's unclear to me whether having a &[MaybeUninit<T>] that's larger than the object it points to, is UB or not. (please ignore, I managed to confuse myself)

cc @RalfJung @gankro @rust-lang/libs

[withoutboats]

Seems like it would not fulfill the use cases of RawVec if it doesn't track the capacity. Could be interesting to change RawVec to use MaybeUninit<T>s though.

[dtolnay]

It tracks the capacity but calls it .len() instead of .capacity.

[withoutboats]

I guess I misunderstood eddy's comment about manipulating the length, he means the length tracked in Vec, not the length tracked by the wide pointer?

[eddyb]

What I meant was the "length" of [MaybeUninit<T>] would be the capacity for [T].
But I realized I jumped the gun on safety, so I edited the issue description.

[strega-nil]

@eddyb why would you have a &[MaybeUninit<T>] that has a bigger length than the object it points to?

(I would classify it as an invalid slice, anyways, and therefore UB to value-convert)

[SimonSapin]

We can probably replace RawVec’s pointer and capacity fields, but its methods still contain a bunch of code that need to live somewhere so it seems unlikely that we’d remove the type entirely.

[scottmcm]

RawVec<T> could safely Deref to [MaybeUninit<T>], right?

[SimonSapin]

I think that would be sound, but would it be useful? RawVec is perma-unstable implementation detail of Vec and VecDeque, not really intended for general use.

[Gankra]

The value of this seems dubious, considering (iirc) RawVec needs to have two "notions" of capacity (stored vs effective) to make it easier to work with ZSTs, and the whole thing would make code a bit more unclear.

[eddyb]

Reopened because of renewed interest:

• replace RawVec with Boxed slice #94421

[RalfJung]

See #94421 (comment) for some of the fall-out of doing this: by using Box, this becomes subject to the Box aliasing guarantees, which is in conflict with some modes of use of Vec that rely on being able to push without invalidating existing pointers (which seems to be encouraged by the documentation, and there are tests ensuring it works correctly in Miri).

Maybe there is a way to have weaker aliasing guarantees for Box, but there is only so much we can weaken them before we have to stop emitting noalias for Box arguments.
Also see rust-lang/unsafe-code-guidelines#326.