Can lifetimes affect layouts?

[mikeyhew]

Is it possible, given the following trait, for <T as Foo<'a>>::Output and <T as Foo<'b>>::Output to have different layouts in memory?

trait Foo<'a> {
    type Output;
}

I'm asking because std::mem::transmute gives me an error when transmuting between the two: Rust Playground

If it is possible for them to have different layouts, do you have an example?

[scottmcm]

With specialization they can, though that's also the case where specialization is unsound today.

[steffahn]

Which is a long/indirect way of saying “they can't have different layouts”?

[LegionMammal978]

I'm pretty sure that this would be an example of a "dependently-sized type" that the error message mentions. As I understand it, transmute expects to know the exact size at the call site. Since the <T as Foo<'_>>::Output projections can't be normalized into a specific type, transmute does not attempt to do any further reasoning. See also rust-lang/rust#61956; a type with a const-generic size can't be transmuted.

[mikeyhew]

Do you have an example of how this could happen? I see a few open issues for unsoundness with specialization, but I'm not sure how I would use one of them to get different layouts. They mostly seem to give you a way to turn &'a T into &'static T, but that's not what I'm worried about here.

[jbe]

I had a similar error, but in the context of GATs, recently:

@jbe

Error:

error[E0512]: cannot transmute between types of different sizes, or dependently-sized types
   --> src/lib.rs:930:16
    |
930 |               Ok(std::mem::transmute::<
    |  ________________^
931 | |                 Option<V::AlignedRef<'_>>,
932 | |                 Option<V::AlignedRef<'b>>,
933 | |             >(result))
    | |_____________^
    |
    = note: `Option<<V as Storable>::AlignedRef>` does not have a fixed size

For more information about this error, try `rustc --explain E0512`.

However, I would argue that the two types V::AlignedRef<'lt> and V::AlignedRef<'b> would always have the same size.

[LegionMammal978]

Curiously, 'static specialization seems to override any lifetime-generic defaults. Consider this basic example (Rust Playground):

#![feature(specialization)]

pub trait Trait<'a> {
    type AssocType;
}

pub struct Struct;

impl<'a, T> Trait<'a> for T {
    default type AssocType = ();
}

impl Trait<'static> for Struct {
    type AssocType = i32;
}

pub fn test<'a>() -> <Struct as Trait<'a>>::AssocType {
    unimplemented!()
}

The compiler complains that Struct only implements Trait<'static>. But if the second impl block is commented out, the code compiles with only the incomplete_features lint.

[mikeyhew]

Reading through the issue that @LegionMammal978 linked as well as related issues, it looks like std::mem::transmute just doesn't work on type parameters in general. For example, std::mem::transmute::<T, T>(...) returns the same error even though T and T are clearly the same type.

[kornel]

In current stable Rust they can't. I suspect the error message is too conservative and just sees X::Output vs Y::Output.

[mikeyhew]

For all of you that are interested, I just posted about a crate that I'm working on that is based on the assumption that lifetime can't affect layouts: `borrowed_with_owner`, an alternative to `owning_ref`