Add RFC for new intrinsic design

[brson]

Details in the commit. Transcribed from workweek minutes: https://github.com/mozilla/rust/wiki/Meeting-workweek-2014-03-03#intrinsics.

[bnoordhuis]

Seems reasonable to me FWIW. One question, the RFC mentions:

rustc is forced to inline a great number of tiny intrinsic wrappers, which is bad for both compile-time performance and runtime performance without optimizations.

Does that mean that the #[intrinsic] attribute is implicitly #[inline(always)], #[inline(never)] or neither?

[brson]

@bnoordhuis it's inline(always) but the inlining is done in the front end.

[bnoordhuis]

Maybe this could paragraph could mention that forced inlining is done in the front-end. That wasn't obvious (to me at least) until @brson clarified it.

[Aatch]

Hmm, looks ok to me, but is very sparse on the details.

I'd like to see intrinsics given a little more room in the language, as they are (to me at least) inherently there for bypassing the language semantics (or producing faster code, but that's just a bonus). However currently they are significantly hamstrung by the fact that the typechecker and other parts treat them the same as any other function call, meaning that you either get "type" errors in trans or an explosion of functions that shouldn't really exist.

[nikomatsakis]

@brson while this looks relatively ok to me, I feel like this is missing a big part of what we discussed: in particular, didn't we intend to impose constraints on the type parameters with which transmute can be instantiated? I had hoped to address the problem of transmuting between types of different sizes this way, but also possibly to remove the possibility of "const-casts" (which are undefined behavior) so as to channel interior mutability through Unsafe<T>. (See rust-lang/rust#13146.)

[huonw]

@nikomatsakis would that theoretically require a new kind like T: SameSizeAs<u64> for transmute to be used on generics?

I'd guess one can use macros in those cases, especially since it seems highly likely that any generic function that transmutes a plain generic (i.e. not behind a pointer or anything) is just a small helper, which a macro is perfect for.

[nikomatsakis]

@huonw if we wanted to enable it, then yes, something like that -- or maybe TransmutableTo. In general, transmute applied to raw generic types is a dangerous sign -- but it can be used legitimately, if the caller controls all types that it will ever be used on.

Private traits still offer a reasonable alternative. You can create a private trait like:

trait TransmutableTo<T> { 
    unsafe fn transmute_to(from: self) -> T;
}

and replace your calls to transmute with TransmutableTo::transmute_to().

Then you just impl that trait for each of the types you expect to use it with:

impl TransmutableTo<Target> for Source {
    unsafe fn transmute_to(self) -> Target { cast::transmute() }
}
...

This is more-or-less what you suggested, but I am not advocating it as a public trait, just something people can use in specific cases. I'd be interested to know if there are legit use cases involving a family of types but not involving pointer indirection.

(Note that the ability to transmute &T to &U, if supported, naturally limits our ability to prevent const casts, but it's still worth trying imo.)

[brson]

@nikomatsakis I consider the restrictions on transmute to be a seperate issue: rust-lang/rust#12898

[nikomatsakis]

@brson oh, ok, I forgot about that (even though I apparently commented)