Array lengths don't support generic parameters.

[roblabla]

EDIT: This can now be made to work on nightly compilers, although it's a bit awkward to use. See this comment.

It would seem that when using size_of in const fn context, it fails to properly compute the size of generic types.

The following function fails

unsafe fn zeroed<T: Sized>() -> T {
    // First create an array that has the same size as T, initialized at 0
    let x = [0u8; std::mem::size_of::<T>()];
    // Then, transmute it to type T, and return it
    std::mem::transmute(x)
}

The error is the following :

error[E0277]: the trait bound `T: std::marker::Sized` is not satisfied
 --> src/main.rs:3:19
  |
3 |     let x = [0u8; std::mem::size_of::<T>()];
  |                   ^^^^^^^^^^^^^^^^^^^^^^ `T` does not have a constant size known at compile-time
  |
  = help: the trait `std::marker::Sized` is not implemented for `T`
  = help: consider adding a `where T: std::marker::Sized` bound
  = note: required by `std::mem::size_of`

This is very confusing because it complains that T doesn't have std::marker::Sized, even though it does have that bound.

Meta

rustc_version : rustc 1.20.0-nightly (ae98ebf 2017-07-20)

[Mark-Simulacrum]

cc @eddyb -- was this intentional?

[eddyb]

This is a limitation of array length - it can't use any parameters in scope - which also came up during the stabilization of associated consts (cc @withoutboats do we have a common issue to use for this?) and the decision taken was to stabilize associated consts without it.

The exact error here comes from the type parameter being resolved, but the ty::Generics and ty::GenericPredicates (bounds, including the default Sized on type parameters) of the array length are actually both empty. They have to be (for now), otherwise we get cycle errors.

[eddyb]

This example triggers a const-evaluation error instead (try on playpen):

fn test<T: ?Sized>() {
    [0u8; std::mem::size_of::<&T>()];
}

cc @GuillaumeGomez @oli-obk Why is the const-eval error printing broken still 😢?

[scottmcm]

This makes me sad, as it's the one thing I wanted to do with #42859 😢

[ExpHP]

Weird thing: You can... um... kind of work around it. (but perhaps you shouldn't)

pub trait ConstSizeOf: Sized {
    const SIZE: usize = ::std::mem::size_of::<Self>();
}

impl<T> ConstSizeOf for T { }

You get a, uh... warning... that sounds extremely serious and that seems to suggest that this will have a very high probability of blowing up in your face.

   Compiling playground v0.0.1 (file:///playground)
warning: constant evaluation error: the type `Self` has an unknown layout
 --> src/main.rs:2:25
  |
2 |     const SIZE: usize = ::std::mem::size_of::<Self>();
  |                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: #[warn(const_err)] on by default

    Finished dev [unoptimized + debuginfo] target(s) in 0.52 secs
     Running `target/debug/playground`

But, um...

it, uh...seems to work.

fn main() {
    // using println instead of assert_eq! to make sure it isn't just optimized
    // away as undefined behavior
    println!("{:?}", <i8>::SIZE); // prints 1
    println!("{:?}", <i16>::SIZE); // prints 2
    println!("{:?}", <i32>::SIZE); // prints 4
    println!("{:?}", <i64>::SIZE); // prints 8
    println!("{:?}", <Vec<()>>::SIZE); // prints 24
    println!("{:?}", <Vec<i8>>::SIZE); // prints 24

    fn test_vec<T>() {
        println!("{:?}", Vec::<T>::SIZE);
    }
    fn test_tuple<T>() {
        println!("{:?}", <(T, T)>::SIZE);
    }
    test_vec::<()>(); // prints 24
    test_vec::<i8>(); // prints 24
    test_tuple::<()>(); // prints 0
    test_tuple::<i8>(); // prints 2
}

[ExpHP]

Oops, never mind.

// error: T: Sized is not satisfied
fn to_byte_array<T>() -> [u8; T::SIZE] {
    panic!()
}

I could have sworn I've done something before with associated consts in array types, though...

[juchiast]

I think we shoud change the error message, this is very confusing now.

[eddyb]

@ExpHP The problem is using type parameters (e.g. your T) in array lengths, everything else works.

@juchiast The error message is "emergent" from the same reason we can't "just" allow this to work right now, the the only other solution I can think of is checking if type-parameters are "really in scope" but that would probably break existing code that doesn't need to look at type parameters.