Generalized Vec, implemented Vec::transmute_buffer.

[JohnScience]

No description provided.

[JohnScience]

Ready for the review!

[JohnScience]

@Dirbaio

[Dirbaio]

you can implement Deref and DerefMut into [T; N] so all the usual slice methods are instantly available, without you having to wrap them.

[JohnScience]

you can implement Deref and DerefMut into [T; N] so all the usual slice methods are instantly available, without you having to wrap them.

Done. And I kept the methods to provide const alternatives.

[reitermarkus]

Does this actually have to be const? If not, may as well remove it again, along with as_mut_ptr and move the cast back.

[Dirbaio]

i'm not 100% convinced we should have transmute_buffer in the public API, it's quite easy to misuse and a bit niche. With the alignment generic, it should be possible for user code to safely do any transmuting on its own.

[JohnScience]

i'm not 100% convinced we should have transmute_buffer in the public API, it's quite easy to misuse and a bit niche. With the alignment generic, it should be possible for user code to safely do any transmuting on its own.

In defense of transmute buffer, this method is the primary reason for addition of the alignment type parameter.

In order to avoid the pollution of the namespace, this method is provided only for T=u8.

impl<const N: usize, A> Vec<u8, N, A> {
 // fn transmute_buffer
}

I'll try elaborate on the choice here. In order to make the transmutation in user code safe, it has to either expose this function (transmute_buffer) or expose the buffer. Otherwise, it'd be impossible/hard to do safely. And I believe that hiding this implementation detail is quite important.

[JohnScience]

Ready for review!

[JohnScience]

@reitermarkus Fixed

[JohnScience]

@reitermarkus Fixed.

[Dirbaio]

I'll try elaborate on the choice here. In order to make the transmutation in user code safe, it has to either expose this function (transmute_buffer) or expose the buffer.

We already expose the buffer with .as_ptr() / .as_mut_ptr(), so it's already possible to do transmute_buffer from user code soundly.

[JohnScience]

I'll try elaborate on the choice here. In order to make the transmutation in user code safe, it has to either expose this function (transmute_buffer) or expose the buffer.

We already expose the buffer with .as_ptr() / .as_mut_ptr(), so it's already possible to do transmute_buffer from user code soundly.

Another reason why I'm not particularly happy with leaving this to the user is that with the stabilization of std::intrinsics::transmute_unchecked we will be able to no longer rely on the optimization of the unnecessary copy created with std::mem::transmute_copy. However, we won't be able to change the code of the library users if we delegate this responsibility to them.

Later on, we'll be able to deprecate the method and one day eventually even remove it if there's a need for a major update (= other breaking changes).

EDIT:

I thought more about it and I think it's alright to remove the method because this fix can be applied with Clippy.

[reitermarkus]

@JohnScience, can you rebase this?