Basic Types

// Miscellaneous
void
noreturn	// encodes __attribute__((noreturn)) and similar
bool
null_t		// the type of `null`; TBD: what to name this keyword? (again, I dislike ones ending with _t)
// TODO: Actual name of type?
dynamic		// top type, essentially a boxed/variant type with some magic attached to it

// Character Types
char	// equivalent to uint8_t in representation, but a separate type for clarity
wchar	// reserved; uint16_t-based
dchar	// reserved; uint32_t-based
// note that strings are simply immutable `char[]`
// TODO: Should strings be a separate type in their own right? Could make `char` 32-bit, or even a higher-level grapheme cluster type in that case (but grapheme clusters imply single Unicode version dependency).

// Integers
// TODO: Should we use [u]int{8,16,32,64,128} instead?
byte ubyte		// 8-bit
short ushort	// 16-bit
int uint		// 32-bit
long ulong		// 64-bit
cent ucent		// reserved; 128-bit

// Floating-Point Types
// TBD: reserve keywords for half-float and quad-float?
float	// 32-bit
double	// 64-bit
real	// TBD; likely to be "implementation-defined" (typically 32-bit or 64-bit, depending on what it's embedded in)

// Common Aliases (technically part of an implicitly-imported module, though some may become keywords)
string				// immutable char[]
mstring				// char[]
asize_t				// a type that can store the longest arrays; might not necessarily be the same as `uintword`, as this may be reduced
intword uintword	// sort of like [u]intptr_t, a type large enough to store certain useful things; always 64-bit in VM, but e.g. JavaScript, WebASM, or native builds may be 32-bit in some cases.

// TODO: Should we have a `bigint` in core?
// Also: Someone did suggest replacing `int` with it (and renaming "old" int to `int32`, etc), but I dislike the performance implications of the replacement.