carbon-lang/docs/design/primitive_types.md

Primitive types

Table of contents

• TODO
• Overview
  • Integers
  • Floats
  • BFloat16
• Open questions
  • Primitive types as code vs built-in
  • String view vs owning string
  • Syntax for wrapping operations
  • Non-power-of-two sizes

TODO

This is a skeletal design, added to support the overview. It should not be treated as accepted by the core team; rather, it is a placeholder until we have more time to examine this detail. Please feel welcome to rewrite and update as appropriate.

Overview

These types are fundamental to the language as they aren't either formed from or modifying other types. They also have semantics that are defined from first principles rather than in terms of other operations. These will be made available through the prelude package.

• bool - a boolean type with two possible values: true and false.
• Signed and unsigned 64-bit integer types:
  • Standard sizes are available, both signed and unsigned, including i8, i16, i32, i64, and i128, and u8, u16, u32, u64, and u128.
  • Signed overflow in either direction is an error.
• Floating points type with semantics based on IEEE-754.
  • Standard sizes are available, including f16, f32, and f64.
  • BFloat16 is also provided.
• String - a byte sequence treated as containing UTF-8 encoded text.
  • StringView - a read-only reference to a byte sequence treated as containing UTF-8 encoded text.

The names bool, true, and false are keywords, and identifiers of the form i[0-9]*, u[0-9]*, and f[0-9*] are type literals, resulting in the corresponding type.

Integers

Integer types can be either signed or unsigned, much like in C++. Signed integers are represented using 2's complement and notionally modeled as unbounded natural numbers. Signed overflow in either direction is an error. Specific sizes are available, for example: i8, u16, i32, and u128.

There is an upper bound on the size of an integer, most likely initially set to 128 bits due to LLVM limitations.

Floats

Floating point types are based on the binary floating point formats provided by IEEE-754. f16, f32, f64 and, if available, f128 correspond exactly to those sized IEEE-754 formats, and have the semantics defined by IEEE-754.

BFloat16

Carbon also supports the BFloat16 format, a 16-bit truncation of a "binary32" IEEE-754 format floating point number.

Open questions

Primitive types as code vs built-in

There are open questions about the extent to which these types should be defined in Carbon code rather than special. Clearly they can't be directly implemented w/o help, but it might still be useful to force the programmer-observed interface to reside in code. However, this can cause difficulty with avoiding the need to import things gratuitously.

String view vs owning string

The right model of a string view versus an owning string is still very much unsettled.

Syntax for wrapping operations

Open question around allowing special syntax for wrapping operations (even on signed types) and/or requiring such syntax for wrapping operations on unsigned types.

Non-power-of-two sizes

Supporting non-power-of-two sizes is likely needed to have a clean model for bitfields, but requires more details to be worked out around memory access.