Rename `from_raw_part` to `from_raw`

[cmazakas]

Rename `from_raw_part` to `from_raw`

[Plecra]

This seems like a good idea. Imo it'd be better to mirror the Box "raw" API, since it's closer to the model that minivec would be used for. So I'd go a little further and

• Remove from_raw_parts
• Add into_raw
  • Which would look something like

    /// Returns a pointer to `self.len()` `T`s
    fn into_raw(self) -> *mut T {
        let mut vec = mem::ManuallyDrop::new(self);
        self.as_mut_ptr()
    }

• Define from_raw to (strictly) only be valid on a value returned from into_raw

[DoumanAsh]

minivec should mimic Vec as much as possible actually.
into_raw makes a little sense as you lose ability to get meta information (capacity, length) by destroying vector.
Either it should be into_raw_parts or use can sue as_mut_ptr and managing forget himself.

On that note from_raw_parts should be re-considered to not panic on changed length and instead update header with new length. (i.e. this should be replaced)
Capacity though should not be the case, as user must avoid re-allocating himself

[Plecra]

MiniVec whole purpose is to be able to be passed as a single pointer, mirroring the guarantee that Box gives about using its pointers in FFI. As the thing that makes this API "special", I'd find it clearer to give it a relevant name.

Vec::into_raw_parts isn't even stable yet - you need to use Vec::{len, capacity} individually, and there's nothing stopping you from doing the same with MiniVec. There's just no reason you'd want to.

That said, constructing the MiniVec with a new length is important to consider. I'd prefer a from_raw_with_length API.

[DoumanAsh]

Let's not guess @LeonineKing1199 intentions here.
Although I know from talking with him that the only goal is to provide Vec with size of pointer.

[Plecra]

Right, which the documentation explains is useful for FFI. I suppose it might also speed things up if you're passing something like [Vec<T>; 64] around the stack, but things like vec == "foobar" are going to be slower due to cache misses. It'll only be useful for performance in very niche cases.

And we have to consider what the API is being used for: MiniVec doesn't define its representation, so you can't use the API for low level manipulations. I don't know why you'd want a raw pointer unless you were writing FFI code.

[cmazakas]

Although I know from talking with him that the only goal is to provide Vec with size of pointer.

It was originally but I like the idea of adding more zing here.

I made from_raw_part because I could implement from_raw_parts and I wanted to show off.

With this function, we've already diverged from the Vec API so I think we should go all the way and make something good.

Add into_raw
Define from_raw to (strictly) only be valid on a value returned from into_raw

Let's make these happen.

into_raw makes a little sense as you lose ability to get meta information (capacity, length) by destroying vector.

We make this work by returning the result of MiniVec::as_mut_ptr which returns an offset into the buf_ member.

In the from_raw call, we'd take the pointer and assume the header is to the left.

On that note from_raw_parts should be re-considered to not panic on changed length and instead update header with new length. (i.e. this should be replaced)
Capacity though should not be the case, as user must avoid re-allocating himself

Hey, good catch with this! If a user was to call into_raw_parts and then feed it to a C API which destructs elements or the user manually resets the len to leak elements or just not run destructors, from_raw_parts for us would end horribly.

I'll make an issue to track this as well.