Skip to content

Commit

Permalink
Initial draft of copy ergonomics design note
Browse files Browse the repository at this point in the history
This draws mostly on readily available links in
rust-lang/rust#44619.
  • Loading branch information
Mark-Simulacrum committed Oct 20, 2020
1 parent 7645e56 commit d9502d0
Show file tree
Hide file tree
Showing 2 changed files with 56 additions and 0 deletions.
2 changes: 2 additions & 0 deletions src/SUMMARY.md
Original file line number Diff line number Diff line change
Expand Up @@ -9,3 +9,5 @@
- [Proposing a new project](./proposing_a_project.md)
- [Design notes](./design_notes.md)
- [Allowing integer literals like `1` to be inferred to floating point](./design_notes/int_literal_as_float.md)
- [Generalized coroutines](./design_notes/general_coroutines.md)
- [Copy type ergonomics](./design_notes/copy_ergonomics.md)
54 changes: 54 additions & 0 deletions src/design_notes/copy_ergonomics.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,54 @@
# Copy type ergonomics

## Background

There are a number of pain points with `Copy` types that the lang team is
interested in exploring, though active experimentation is not currently ongoing.

Some key problems are:

## `Copy` cannot be implemented with non-`Copy` members

There are standard library types where the lack of a `Copy` impl is an
active pain point, e.g., [`MaybeUninit`](https://github.com/rust-lang/rust/issues/62835)
and [`UnsafeCell`](https://github.com/rust-lang/rust/issues/25053)

### History

* `unsafe impl Copy for T` which avoids the requirement that T is recursively
Copy, but is obviously unsafe.
* https://github.com/rust-lang/rust/issues/25053#issuecomment-218610508
* `Copy` is dangerous on types like `UnsafeCell` where `&UnsafeCell<T>`
otherwise would not permit access to `T` in [safe
code](https://github.com/rust-lang/rust/issues/25053#issuecomment-98447164).

## `Copy` types can be (unintentionally) copied

Even if a type is Copy (e.g., `[u8; 1024]`) it may not be a good idea to make
use of that in practice, since copying large amounts of data is slow.

This also comes up with `Copy` impls on `Range`, which would generally be
desirable but is error-prone given the `Iterator/IntoIterator` impls on ranges.

Note that "large copies" comes up with moves as well (whih are copies, just
taking ownership as well), so a size-based lint is plausibly desirable for both.

### History

* Tracking issue: [#45683](https://github.com/rust-lang/rust/issues/45683)

## References to `Copy` types

Frequently when dealing with code generic over T you end up needing things like
`[u8]::contains(&5)` which is ugly and annoying. Iterators of copy types also
produce `&&u64` and similar constructs which can produce unexpected type errors.

There is also plausibly performance left on the table with types like `&&u64`.

Note that this interacts with the unintentional copies (especially of large
structures).

### History

* [RFC 2111 (not merged)](https://github.com/rust-lang/rfcs/pull/2111)
* [Rust tracking issue (closed)](https://github.com/rust-lang/rust/issues/44763)

0 comments on commit d9502d0

Please sign in to comment.