Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Safe memcpy for slices ([T]::copy_from_slice) #1419

Merged
merged 12 commits into from
Feb 18, 2016
60 changes: 60 additions & 0 deletions text/0000-slice-copy.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,60 @@
- Feature Name: slice\_copy\_from
- Start Date: (fill me in with today's date, YYYY-MM-DD)
- RFC PR: (leave this empty)
- Rust Issue: (leave this empty)

# Summary
[summary]: #summary

Safe `memcpy` from one slice to another of the same type and length.

# Motivation
[motivation]: #motivation

Currently, the only way to quickly copy from one non-`u8` slice to another is to
use a loop, or unsafe methods like `std::ptr::copy_nonoverlapping`. This allows
us to guarantee a `memcpy` for `Copy` types, and is safe.

# Detailed design
[design]: #detailed-design

Add one method to Primitive Type `slice`.

```rust
impl<T> [T] where T: Copy {
pub fn copy_from_slice(&mut self, src: &[T]);
}
```

`copy_from_slice` asserts that `src.len() == self.len()`, then `memcpy`s the
members into `self` from `src`. Calling `copy_from_slice` is semantically
equivalent to a `memcpy`. `self` shall have exactly the same members as `src`
after a call to `copy_from_slice`.

# Drawbacks
[drawbacks]: #drawbacks

One new method on `slice`.

# Alternatives
[alternatives]: #alternatives

`copy_from_slice` could be called `copy_to`, and have the order of the arguments
switched around. This would follow `ptr::copy_nonoverlapping` ordering, and not
`dst = src` or `.clone_from_slice()` ordering.

`copy_from_slice` could panic only if `dst.len() < src.len()`. This would be the
same as what came before, but we would also lose the guarantee that an
uninitialized slice would be fully initialized.

`copy_from_slice` could be a free function, as it was in the original draft of
this document. However, there was overwhelming support for it as a method.

`copy_from_slice` could be not merged, and `clone_from_slice` could be
specialized to `memcpy` in cases of `T: Copy`. I think it's good to have a
specific function to do this, however, which asserts that `T: Copy`.

# Unresolved questions
[unresolved]: #unresolved-questions

None, as far as I can tell.