Tracking issue for std::slice::bytes

[alexcrichton]

This is a tracking issue for the unstable slice_bytes feature in the standard library. This module has some various helper methods for dealing with blocks of bytes in an efficient fashion, but they seem particularly one-off and not necessarily fitting in with the rest of the design of the standard library.

Some drawbacks are:

• A one-off trait MutableByteVector is used to give slices the set_memory method.
• A one-off and oddly placed copy_memory function is used to provide essentially safe bindings to memcpy

Both of these can be implemented in stable Rust otherwise and get optimized down to the same implementation, but it's often useful to call them directly to guarantee the optimization will happen. Needs a decision to whether this functionality should be exposed, where it should be exposed, and how.

[cesarb]

I tend to copy that module to every single project I write in Rust (for instance, https://github.com/cesarb/blake2-rfc/blob/master/src/bytes.rs), as a safe and easy-use implementation of memset and memcpy. It's very useful to, for instance, zero the tail of a buffer (memset), or copy from a buffer to another (memcpy). And since I copied them from the standard library, I can be quite certain that the implementation is correct.

They do optimize down to either direct moves/writes through vector registers or to straight calls to memset/memcpy, so I don't see how it being in the standard library would guarantee any optimization over a local copy of the exact same code.

I believe this functionality should be exposed, as it's very useful when dealing with byte (u8) buffers.

The question is how to expose it. The current way works well, but looks strange.

• For memset, you have to import bytes::MutableByteVector, but it's called x.set_memory(0). The connection between both is not intuitive.
• For memcpy, on the other hand, you import and use the copy_memory function directly.

This design inconsistency becomes very obvious when you want to use both:

use ...::bytes::{MutableByteVector, copy_memory};

IMHO, either both should be standalone functions, or both should be in a trait:

• Standalone functions: set_memory(dst: &mut [u8], value: u8), copy_memory(src: &[u8], dst: &mut [u8]) (perhaps flip the parameter order of one of them for consistency).
• With a trait, we could use a single trait (IMHO this is the cleanest option):

pub trait MutableByteVector {
    fn set_memory(&mut self, value: u8);
    fn copy_memory_from(&mut self, src: &[u8]);

    // We could perhaps even add a memmove here, like:
    fn move_memory(&mut self, dst_offset: usize, src_offset: usize, len: usize);
    // although I don't know how useful that would be
}

Another question is where to expose it. I don't see much point on that single-use module, so either directly on std::slice or on std::mem would be my options.

[cesarb]

If you want, I could write a RFC for the trait alternative (without memmove).

[aturon]

Nominating for discussion for 1.6. Discuss post.

cc @briansmith

[alexcrichton]

🔔 This issue is now entering its cycle-long final comment period for deprecation 🔔

[alexcrichton]

The libs team discussed this during triage today and the decision was to deprecate

[SimonSapin]

Is there a recommended, stable replacement for this functionality?

[alexcrichton]

Yes, basically just using iterators and loops.

[SimonSapin]

That’s, hum, unfortunate. Writing a trivial loop like this is annoying enough that it’s tempting (IMO) to use std::ptr::copy_nonoverlapping instead. But it’s unsafe, so there’s always a risk of getting it wrong.

I think this functionality belongs in the standard library, whatever its API looks like.

[alexcrichton]

It's likely this can either be replaced via clone_from_slice or perhaps a new API fill for slices which clones an element into every element of the slice.