Thin pointers with inline metadata

[frank-king]

This RFC introduces a Thin wrapper which thinifies a fat pointer of a DST by inlining its metadata.

Rendered.

Pre-RFC on Rust Internal Forum.

Important

When responding to RFCs, try to use inline review comments (it is possible to leave an inline review comment for the entire file at the top) instead of direct comments for normal comments and keep normal comments for procedural matters like starting FCPs.

This keeps the discussion more organized.

[clarfonthey]

It is unfortunate that we can't fit Vec into this representation, but I feel like custom DSTs could eventually make it work with Thin, so, I'm not too upset about it.

[frank-king]

Do you mean making std::vec::Vec<T> a thin pointer? What's the advantage compared to the current representation?

[clarfonthey]

Yeah, specifically the fact that there's no way to represent a partially initialised slice like a Vec in a generic way. It would be cool if Vec<T> were Box<PartiallyInitSlice<T>> and ThinVec<T> were Box<Thin<PartiallyInitSlice<T>>.

[frank-king]

Can I understand the PartiallyInitSlice<T> as a [MaybeUninit<T>] with an extra metadata inited_len: uszie indicating the number of initialized elements in this slice? Sounds cool!

[frank-king]

But that requires DST of mutable metadata, or it is not possible to implement a push method for an &mut PartiallyInitSlice<T>

[clarfonthey]

Right, under this situation, you'd still need to be implementing stuff for &mut Box directly, but at least the types are compatible with Thin.

I don't treat any of this as a set-in-stone proposal; my main point is that Thin not working for Vec now doesn't mean it can't necessarily work in the future, just, it would require extra stuff we don't have yet. And so, it not working for Vec shouldn't mean Thin as-is needs any particular changes to account for that.

[frank-king]

Agreed.

[frank-king]

Probably I can add this point to the "Future possibility" section?

[clarfonthey]

Yeah, feel free to reword any amount of what I said and add it to the RFC!

I think that maybe making the capacity of a vec part of the metadata could be a useful step toward allowing some kind of ArrayVec solution in libstd, or at least making array::IntoIter less redundant, but there are a lot of different paths and we're not sure what path we'll take. But in terms of generalising ThinVec, it seems promising.