Change:
Here's the definition Implementing is done like so: A safe implementation invokes a transmute between arbitrary types. Perhaps is more appropriately an unsafe trait?
Agreed. Unsafe trait is the way to go.

Discussion:
use marker::Copy; use mem; <del> /// The representation of a Rust slice </del> <ins> /// The representation of a slice like `&[T]`. /// /// This struct is guaranteed to have the layout of types like `&[T]`, /// `&str`, and `Box<[T]>`, but is not the type of such slices /// (e.g. the fields are not directly accessible on a `&[T]`) nor does /// it control that layout (changing the definition will not change /// the layout of a `&[T]`). It is only designed to be used by unsafe /// code that needs to manipulate the low-level details. /// /// However, it is not recommended to use this type for such code, /// since there are alternatives which may be safer: /// /// - Creating a slice from a data pointer and length can be done with ///   `std::slice::from_raw_parts` or `std::slice::from_raw_parts_mut` ///   instead of `std::mem::transmute`ing a value of type `Slice`. /// - Extracting the data pointer and length from a slice can be ///   performed with the `as_ptr` (or `as_mut_ptr`) and `len` ///   methods. /// /// If one does decide to convert a slice value to a `Slice`, the /// `Repr` trait in this module provides a method for a safe /// conversion from `&[T]` (and `&str`) to a `Slice`, more type-safe /// than a call to `transmute`. /// /// # Examples /// /// ``` /// use std::raw::{self, Repr}; /// /// let slice: &[u16] = &[1, 2, 3, 4]; /// /// let repr: raw::Slice<u16> = slice.repr(); /// println!("data pointer = {:?}, length = {}", repr.data, repr.len); /// ``` </ins> #[repr(C)] pub struct Slice<T> { pub data: *const T,

impl<T> Copy for Slice<T> {} <del> /// The representation of a Rust closure </del> <ins> /// The representation of an old closure. </ins> #[repr(C)] #[derive(Copy)] <ins> #[unstable(feature = "core")] #[deprecated(reason = "unboxed new closures do not have a universal representation;  `&Fn` (etc) trait objects should use `TraitObject` instead", since= "1.0.0")] </ins> pub struct Closure { pub code: *mut (), pub env: *mut (), } <del> /// The representation of a Rust trait object. </del> <ins> /// The representation of a trait object like `&SomeTrait`. /// /// This struct has the same layout as types like `&SomeTrait` and /// `Box<AnotherTrait>`. The [Static and Dynamic Dispatch chapter of the /// Book][moreinfo] contains more details about the precise nature of /// these internals. /// /// [moreinfo]: ../../book/static-and-dynamic-dispatch.html#representation /// /// `TraitObject` is guaranteed to match layouts, but it is not the /// type of trait objects (e.g. the fields are not directly accessible /// on a `&SomeTrait`) nor does it control that layout (changing the /// definition will not change the layout of a `&SometTrait`). It is /// only designed to be used by unsafe code that needs to manipulate /// the low-level details. /// /// There is no `Repr` implementation for `TraitObject` because there /// is no way to refer to all trait objects generically, so the only /// way to create values of this type is with functions like /// `std::mem::transmute`. Similarly, the only way to create a true /// trait object from a `TraitObject` value is with `transmute`. /// /// Synthesizing a trait object with mismatched types—one where the /// vtable does not correspond to the type of the value to which the /// data pointer points—is highly likely to lead to undefined /// behaviour. /// /// # Examples /// /// ``` /// use std::mem; /// use std::raw; /// /// // an example trait /// trait Foo { ///     fn bar(&self) -> i32; /// } /// impl Foo for i32 { ///     fn bar(&self) -> i32 { ///          *self + 1 ///     } /// } /// /// let value: i32 = 123; /// /// // let the compiler make a trait object /// let object: &Foo = &value; /// /// // look at the raw representation /// let raw_object: raw::TraitObject = unsafe { mem::transmute(object) }; /// /// // the data pointer is the address of `value` /// assert_eq!(raw_object.data as *const i32, &value as *const _); /// /// /// let other_value: i32 = 456; /// /// // construct a new object, pointing to a different `i32`, being /// // careful to use the `i32` vtable from `object` /// let synthesized: &Foo = unsafe { ///      mem::transmute(raw::TraitObject { ///          data: &other_value as *const _ as *mut (), ///          vtable: raw_object.vtable ///      }) /// }; </ins> /// <del> /// This struct does not have a `Repr` implementation /// because there is no way to refer to all trait objects generically. </del> <ins> /// // it should work just like we constructed a trait object out of /// // `other_value` directly /// assert_eq!(synthesized.bar(), 457); /// ``` </ins> #[repr(C)] #[derive(Copy)] pub struct TraitObject {

/// This trait is meant to map equivalences between raw structs and their /// corresponding rust values. <del> pub trait Repr<T> { </del> <ins> pub unsafe trait Repr<T> { </ins> /// This function "unwraps" a rust value (without consuming it) into its raw /// struct representation. This can be used to read/write different values /// for the struct. This is a safe method because by default it does not

fn repr(&self) -> T { unsafe { mem::transmute_copy(&self) } } } <del> impl<T> Repr<Slice<T>> for [T] {} impl Repr<Slice<u8>> for str {} </del> <ins> unsafe impl<T> Repr<Slice<T>> for [T] {} unsafe impl Repr<Slice<u8>> for str {} </ins>