transmute safety guidelines handle fat pointers incorrectly

[nikomatsakis]

The code incorrectly assumes that a type parameter which is not known to meet Sized will not meet Sized. So this code fails:

use std::mem::transmute;

fn foo<T, Sized? U>(x: &[T]) -> &U {
    unsafe { transmute(x) }
}

fn main() {
    let x = [1, 2, 3];
    foo::<int, int>(&x);
}

I'm overhauling how we handle Sized and will fix this to be more conservative, I guess.

However, I think that long term this approach of baking in weird rules around the transmute intrinsic is not good. It might be better (and perhaps just as easy or easier?) to have transmute reference a "magic" trait SameSize. This would allow generic code to expose and "bubble up" the transmutable requirement to its parents. It would also be useful for some of the in-place vec methods.

[pythonesque]

I think that in general there are a lot of cases where transmute (or a transmute-a-like) could be statically determined to be safe, where the required knowledge to make it safe seems to be sufficiently specialized that it probably does need to live with an intrinsic. And I can independently think of cases where it would be useful to make assertions about two sizes other than that they were equivalent (for example, wanting to enforce that sizeof(elem1) evenly divides sizeof(elem2)). So I'm not sure that SameSize is really the right generic answer.