Initial primitive types

[adlerjohn]

We'd like to support the following primitive types:

1. Unsigned integers of variable width: u8, u16, u32, u64. Note that the FuelVM only has unsigned integer support for now, as signed integers are of dubious value in the context of smart contracts. Also note that the FuelVM is big-endian.
2. bool: Standard Boolean.
3. byte: A single byte. While we could use u8 like Rust, having a distinct type that forbids certain operations (e.g. arithmetic) without explicit casting increases type safety.
4. bytes32: A 32-byte hash digest.
5. address: A (for now) 32-byte address. This should be a parameter, since we may opt for shorter addresses in the future.

Additionally:

1. Arrays and slices (like Rust's).
2. Tuples (like Rust's).
3. Sum types (like Rust's).

We expect blockchain applications to make heavy use of byte manipulation, and so we should promote these types to primitive types rather than having users go through a standard library for them.

[sezna]

Is there a reason we don't want to support signed integers? Lack of use on the blockchain?

[adlerjohn]

In a blockchain context there's basically zero reason to use negative numbers. You can always express stuff with unsigned ints, e.g. this fairly complex DeFi contract only using unsigned ints: https://github.com/balancer-labs/balancer-core/blob/f4ed5d65362a8d6cec21662fb6eae233b0babc1f/contracts/BMath.sol. The only place I can imagine signed ints being used is in slices, but there are better ways to do that rust-lang/rfcs#2249 (comment).

[sezna]

These types have all been implemented with the exception of the address type, which is tracked in a separate issue. I'm going to close this one.