RFC: Implement base numeric types and bool as a library

[brendanzab]

Here is a (possibly crazy) proposal to remove some magic from the compiler:

#[repr=1 ] pub enum bool { true, false }

#[repr=8 ] pub struct u8;
#[repr=16] pub struct u16;
#[repr=32] pub struct u32;
#[repr=64] pub struct u64;

#[cfg(target_pointer_size = "32")] #[repr=32] pub struct uintptr;
#[cfg(target_pointer_size = "64")] #[repr=64] pub struct uintptr;

#[repr=8 ] pub struct i8;
#[repr=16] pub struct i16;
#[repr=32] pub struct i32;
#[repr=64] pub struct i64;

#[cfg(target_pointer_size = "32")] #[repr=32] pub struct intptr;
#[cfg(target_pointer_size = "64")] #[repr=64] pub struct intptr;

#[repr=32] pub struct f32;
#[repr=64] pub struct f64;

macro_rules! impl_llvm_op(
    ($Binop:ident, $binop:ident, $Self:ident, $init:expr, $llvm_op:ident, $llvm_ty:ident) => (
        impl $Binop<$Self, $Self> For $Self {
            fn $binop(a: &$Self, b: &$Self) -> $Self {
                let (a, b) = (*a, *b);
                unsafe {
                    let ret = &mut $init;
                    llvm!(concat!("%ret = ", stringify!($llvm_op), " ",
                                  stringify!($llvm_ty), " %a, %b")
                        :"a" = a
                        :"b" = b
                        :"ret" = ret
                    )
                    *ret
                }
            }
        }
    )
)

impl_llvm_op!(Add, add, u8, 0, add, i8)
impl_llvm_op!(Add, add, u16, 0, add, i16)
impl_llvm_op!(Add, add, u32, 0, add, i32)
impl_llvm_op!(Add, add, u64, 0, add, i64)

#[cfg(target_pointer_size = "32")] impl_llvm_op!(Add, add, uintptr, 0, add, i32)
#[cfg(target_pointer_size = "64")] impl_llvm_op!(Add, add, uintptr, 0, add, i64)

impl_llvm_op!(Add, add, i8, 0, add, i8)
impl_llvm_op!(Add, add, i16, 0, add, i16)
impl_llvm_op!(Add, add, i32, 0, add, i32)
impl_llvm_op!(Add, add, i64, 0, add, i64)

#[cfg(target_pointer_size = "32")] impl_llvm_op!(Add, add, intptr, 0, add, i32)
#[cfg(target_pointer_size = "64")] impl_llvm_op!(Add, add, intptr, 0, add, i64)

impl_llvm_op!(Add, add, f32, 0.0, fadd, f32)
impl_llvm_op!(Add, add, f64, 0.0, fadd, f64)

This relies on many hypothetical language features including the llvm! macro, CTFE and possibly some way of implementing adding literal assignments, and so might be too ambitious for 1.0. But in the end it could make our language far more extensible and powerful. It might also help simplify our documentation issues with builtin types #10114 #11409

[huonw]

I'd like something like this to fix the documentation issues.

Another similar option would be using lang items like #[lang="bool"] enum Bool { True, False }, #[lang="f32"] struct f32;.

[brendanzab]

Yeah, a less radical proposal could be:

#[repr(u8)]
pub enum bool {
    true = 1,
    false = 0,
}

#[lang="u8"] pub struct u8;
#[lang="u16"] pub struct u16;
#[lang="u32"] pub struct u32;
#[lang="u64"] pub struct u64;
#[lang="uintptr"] pub struct uintptr;

#[lang="i8"] pub struct i8;
#[lang="i16"] pub struct i16;
#[lang="i32"] pub struct i32;
#[lang="i64"] pub struct i64;
#[lang="intptr"] pub struct intptr;

#[lang="f32"] pub struct f32;
#[lang="f64"] pub struct f64;

[glaebhoerl]

I think we should make all built-in types lang items :). So also:

#[lang="ref"] pub struct Ref<'a, T>;
#[lang="ref_mut"] pub struct RefMut<'a, T>;
#[lang="owned_box"] pub struct My<T>; // if this stays built-in at all

And supposing further hypothetical language features:

#[lang="array"] pub struct Array<T, static N: uint>;

(Given good DST str should be implementable entirely as a library, modulo string literals.)

Which part of the original proposal requires CTFE?

[thestinger]

Rust can only evaluate constant expressions using the built-in primitive types at the moment. Calling library code in constant expressions means adding support for at least a limited form of CTFE.

[bill-myers]

How about adding integer generic parameters, and have the uint type be U<n> and the signed one `I``?

[brendanzab]

Which part of the original proposal requires CTFE?

At the moment, numeric operations are hard-wired into the compiler. This allows them to be called at compile time, as in:

pub static BITS : uint = 32;
pub static BYTES : uint = (BITS / 8);

If we removed this magic and implemented the operations in the operator traits directly, people would get very annoyed because their constexprs would stop working. CTFE would also allow us to do other neat things, like implementing casts (ie. the as operator) in the library. Many people, for instance, complain about x as T not working in generic functions - this would solve that.

[brson]

I think such a major redesign is unlikely to happen at this stage.