Tracking Issue for using std::mem::transmute() in const fn (const_fn_transmute)

[TheDarkula]

Using std::mem::transmute() in constant functions is behind the const_transmute/const_fn_transmute feature gate.
(In constants, it is stable.)

Blocked on rust-lang/const-eval#14.

[mjbshaw]

I, for one, would love this, because I've had to use the union transmute hack more times than I feel comfortable. std::mem::transmute is still (super) unsafe, but at least it makes sure the types have the same size.

[TheDarkula]

@mjbshaw It's already been merged :)

[mjbshaw]

@TheDarkula I know. I'm just trying to show support for eventually stabilizing this feature (rather than being removed because people are opposed to it).

[jamesmunns]

Even with the flag, is this possible? I am getting an error stating that the use of unsafe functions are not allowed in const fn:

pub const unsafe fn rx_buffer_init() -> [BufferDescriptor; BUFFER_CT] {
    transmute::<
        [u8; size_of::<BufferDescriptor>() * BUFFER_CT],
        [BufferDescriptor; BUFFER_CT]
    >([0u8; size_of::<BufferDescriptor>() * BUFFER_CT])
}

gives me

error: call to unsafe function is unsafe and unsafe operations are not allowed in const fn
  --> foo/src/test.rs:18:5
   |
18 | /     transmute::<
19 | |         [u8; size_of::<BufferDescriptor>() * BUFFER_CT],
20 | |         [BufferDescriptor; BUFFER_CT]
21 | |     >([0u8; size_of::<BufferDescriptor>() * BUFFER_CT])
   | |____________________________________________________________^ call to unsafe function
   |
   = note: consult the function's documentation for information on how to avoid undefined behavior

[mgostIH]

Is there some blocker on this or could this be starting to get stabilized? I'm mostly looking out for a way to define a function from a u8 array without any indirection but I have no idea whether this is supposed to be supported or not in the design of const fn.

[MSxDOS]

unsafe in const fn has been stabilized in 1.33. Is there anything else left preventing this from being stabilized as well?

EDIT: Ugh, in fact, there is. For example, usize -> function pointer throws

error[E0080]: it is undefined behavior to use this value
...
type validation failed: encountered 10220800, but expected a pointer
|
= note: The rules on what exactly is undefined behavior aren't clear, so this check might be overzealous. Please open an issue on the rust compiler repository if you believe it should not be considered undefined behavior

... which makes const_transmute pretty much useless for me.

[RalfJung]

Given that union field access is already possible inside const (but not inside const fn), it seems somewhat silly to block transmute. All that does is make code less readable by pushing people to use unions instead of transmutes.

So I propose we stabilize transmute in const, but not const fn. However, currently our handling of intrinsics in const-qualif is somewhat broken, so that should be fixed first.

[RalfJung]

See #64011 for stabilizing transmute inside const but not const fn.

[WaffleLapkin]

Is there any news about the stabilization?

[jplatte]

@WaffleLapkin: @oli-obk reopened #64011 today because it got unblocked, then closed it again because apparently stabilizing transmute inside const but not const fn is no longer feasible.

So I think this is now blocked on union accesses in const fn being stabilized (#51909). I don't really understand the path forward for that one based on its comments.

[RalfJung]

Should we give this another try? Not much progress has been made on the unconst side of things (also see here), but allowing transmute where we already allow union could help get rid of a lot of nasty union-type-punning code (probably half of which is wrong because it forgets to add repr(C) to the union).

[oli-obk]

I'm creating a new stabilization PR to show the workarounds needed to allow such a split. We can then decide whether we'll take on that technical debt.

[Ekleog]

Is there any summary of what the current status is here to actually get transmute to be const in const fn?

(Coming here because I'd have liked to make Path::new() const, but AFAIU this requires either pointer deref or transmute to be const, and transmute sounds easier to stabilize than pointer deref)

[RalfJung]

Raw pointers and transmute are pretty much equal in terms of "what it takes to make them const-stable".

The next step is to figure out what we want to do with UB during CTFE, for which I recently proposed an RFC: rust-lang/rfcs#3016. The key PR needed to implement that RFC is up at #78407.

[programmerjake]

I think it would be a good idea to split out into a separate feature that can be stabilized transmute of references to types that are repr(transparent) wrappers:

#[repr(transparent)]
pub struct MySlice(pub [u8]);

impl MySlice {
    pub const fn new(v: &[u8]) -> &MySlice {
        unsafe { std::mem::transmute(v) }
    }
}

[RalfJung]

I think once we find some kind of consensus on rust-lang/rfcs#3016 (which turned out to be much harder than I anticipated), there's not much blocking stabilization here.

[benesch]

So, rust-lang/rfcs#3016 was merged. @RalfJung, does that mean we can proceed with stabilization here?

[benesch]

It seems to me that the answer is probably yes, since #75196 has a stabilization PR out and was previously blocked on rust-lang/const-eval#14.

[RalfJung]

The stabilization PR is already up. :)
#85769