rust-lang / project-safe-transmute

Project group working on the "safe transmute" feature

Project "safe transmute"

A working-group project to extend the Rust language to support safe transmute

• Shepherds:
  • rylev (Ryan)
• Rust lang team contacts:
  • joshtriplett (Josh)
• Our chat room
• The RFC

Contributing

We do not have a formal concept of membership. Please feel free to join our Zulip chat room or to open a GitHub Issues and/or Pull Request.

project-safe-transmute's Issues

Safe transmute between #[repr(transparent)] and the type it contains

I'd like to write the following code:

/// A newtype wrapper around u32 that guarantees the number is even
#[repr(transparent)]
pub struct EvenU32(u32);

impl EvenU32 {
  pub fn try_from_u32_ref(value: &u32) -> Result<&Self, ()> {
    if *value % 2 == 0 {
      Ok(safe_transmute(value))
    } else {
      Err(())
    }
  }
}

To enforce the invariant of the wrapper type, safe_transmute should look at the visibility of the field. For example, the following code in a different module would not work:

// Should not compile, because the `u32` field is inaccessible from the outside
let _: EvenU32 = safe_transmute(&100);

CC @Manishearth

Safe std::mem::uninitialized too?

I might be nice to get that back for "plain old data". Couldn't many of the same analyses that support safe transmute also support that?

Zulip room not linked

The part in the README.md that would link to the zulip room is blank.

Integrate prior art from Typic

Typic seems to be pushing the envelope on what kind of transmutes can be made possible in safe Rust.

I'm opening this issue so that you're aware of it and can integrate it in the RFC as prior art.

Why does the cast_slice parameter have to be of type Pod?

pub fn try_cast_slice<A: Pod, B: Pod>(a: &[A]) -> Result<&[B], PodCastError>
requires that the parameter a is a slice of type Pod. Pods can't be chars (because the type must allow any bit pattern).

However I don't understand why. It's not like I can introduce illegal bit patterns through a non-mutable reference?!
Is this some random limitiation of this crate?

Can we not fix this because of #41?
Is relaxing trait boundaries not allowed?

Comments/prior art on `Atomic<T>`

I was not sure where best to comment this RFC draft. I just wanted to throw a library of mine into the discussion: atomig, which main feature is Atomic<T>.

In atomig's case, the trait bounds on T are a bit more specific and deliberate than in the RFC draft. The docs should explain all the traits fairly well, so I won't repeat myself here.

But one important aspect of having more specific traits: some methods, like fetch_add and fetch_or are bounded by AtomInteger and AtomLogic traits respectively, which in turn are only implemented for types on which integer operations and logical operations make sense, respectively. With the current draft, one could have an Atomic<f32> and call fetch_add on it, but get garbage back, as the atomic add operation is an integer addition. Again, I think the docs should explain this nicely.

Just wanted to throw that out here.

CC @jswrenn

`[T]::safe_align_to` and SIMD

Thought I'd mention that having a safe version of [T]::align_to would be quite handy for SIMD strip-mining loops.

Came up here: https://rust-lang.zulipchat.com/#narrow/stream/257879-project-portable-simd/topic/Meeting.202021-10-25/near/259023018